IBM System/3 
RPG I! Additional Topics 
Programmer’s Guide 


Program Numbers: 
5702-RG1 (Model 10) 
5704-RG1 (Model 15) 
5704-RG2 (Model 15) 
5705-RG1 (Model 12) 


Page of GC21-7567-2 
Issued 30 June 1978 
By TNL: GN21-5616 


Third Edition (July 1974) 


This is a major revision of, and obsoletes, GC21-7567-1. information concerning IBM 
System/3 Model 15 has been added and numerous corrections have been made. Changes to 
text and illustrations are indicated by a vertical line to the left of the change; new or 
extensively revised illustrations are denoted by the symbol @ at the left of the caption. 


This edition applies to the following IBM System/3 RPG #1 program products: 


Version Modification ~ Program Number System/3 Model 
15 00 5702-RG1 8 and 10 Disk 

6 00 5704-RG1 15A,B,C 

2 00 5704-RG2 15D 

4 00 5705-RG1 12 


Changes are periodically made to the information herein; before using this publication 
in connection with the operation of IBM systems, refer to the latest /BM System/3 
Bibliography, GC20-8080, for the editions that are applicable and current. 


This publication contains examples of data and reports used in daily business operations. 
To illustrate them as completely as possible, the examples include the names of 
individuals, companies, brands, and products. All of these names are fictitious and any 
similarity to the names and addresses used by an actual business enterprise is entirely 
coincidental. 


Use this publication only for the purposes stated in the Preface. 


Publications are not stocked at the address below. Requests for copies of IBM publications 
and for technical information about the system should be made to your IBM representative 
or to the IBM branch office serving your locality. 


This publication could contain technical inaccuracies or typographical errors. Use the 
Reader’s Comment Form at the back of this publication to make comments about this 
publication. If the form has been removed, address your comments to [BM Corporation, 
Publications, Department 245, Rochester, Minnesota 55901. Comments become the 
property of IBM. 


© International Business Machines Corporation 1971, 1974 






IBM System/3 
RPG I! Additional Topics 
Programmer's Guide 


©IBM Corp. 1971, 1974 


—S=-= Technical Newsletter This Newsletter No. 


Date 


Base Publication No. 


File No. 


Previous Newsletters 


GN21-5709 
21 December 1979 


GC21-7567-2 
$3-28 


GN21-5616 
GN21-5389' 


This technical newsletter applies to current versions and modifications of the applicable System/3 
programs listed in the edition notice, and provides replacement pages for the subject publication. 
These replacement pages remain in effect for subsequent versions and modifications unless 
specifically altered. Pages to be inserted and/or removed are: 


v through viii (text rearranged) 
3-7, 3-8 

3-17, 3-18 

5-65, 5-66 

5-75, 5-76 

6-33, 6-34 

6-37, 6-38 


6-47, 6-48 

7-7 through 7-10 
7-19, 7-20 

7-31, 7-32 

9-49, 9-50 
10-41, 10-42 


Changes to text and illustrations are indicated by a vertical line at the left of the change. 


Summary of Amendments 


Miscellaneous technical changes 


Note: Please file this cover letter at the back of the manual to provide a record of changes. 


IBM Corporation, Publications, Department 245, Rochester, Minnesota 55901 


CYVIRAA Carn 1070 


Technical Newsletier pi anictaith > MENDARBIG 
Date 30 June 1978 





Base Publication No. GC21-7567-2 
FileNo, 53-28 


) 


Previous Newsletters GN21-5389 


IBM System/3 
RPG I! Additional Topics 
Programmer's Guide 


©1BM Corp. 1971, 1974 


This technical newsletter applies to the current versions and modifications of the applicable 
System/3 programs listed in the edition notice and provides replacement pages for the subject 
publication. These replacement pages remain in effect for subsequent versions and modifications 
unless specifically altered. Pages to be inserted and/or removed are: 


Cover 
Title Page, Edition Notice 


) v, vi 
3-11 through 3-16 
4-3, 4-4 
4-27, 4-28 
5-53 through 5-56 
5-56.1 through 5-56.6 (added to accommodate new and moved text) 
5-77, 5-78 


Changes to text and illustrations are indicated by a vertical line at the left of the change. 


Summary of Amendments 
@ Expanded description of the RPG I! Linkage Editor, page 5-54 


@ Included miscellaneous technical changes 


Note: Please file this cover letter at the back of the manual to provide a record of changes. 


IBN! Corporation, Publications, Department 245, Rochester, Minnesota 55901 


©iBM Corp. 1978 . Printed in U.S.A. 


Date 24 May 1976 


—_ Technical Newsletter | This Newsletter No. ena 


2 ’ Base Publication No. GC21-7567-2 
ae, | | 
ee | FileNo.  $3-28 


Previous Newsletters None 


IBM System/3_ 
RPG 1! Additional Topics 
Programmer's Guide 


©IBM Corp. 1971, 1974 


This technical newsletter provides replacement pages for the subject publication. Pages to be 
inserted and/or removed are: 


i, ii 5-9, 5-10 9-1, 9-2 
1-5, 1-6 5-49, 5-50 ~ 9-27, 9-28 
3-21, 3-22 — 5-67, 5-68 9-41 through 9-44 
3-27 through 3-32 5-77 through 5-80 9-49, 9-50 

. 3-39, 3-40 6-9, 6-10 9-55, 9-56 

) — 4-3, 4-4 7-9, 7-10 10-11 through 10-14 
4-7, 4-8 7-19 through 7-22 10-21 through 10-24 
5-5, 5-6 8-27, 8-28 


Changes to text and illustrations are indicated by a vertical line at the left of the change; new or 
extensively revised illustrations are denoted by the symbol @ at the left of the caption. 


“Summary of Amendments 


@ References to Model 8 and Model 12 have been added. 
e Miscellaneous additions and corrections. 


Note: Please file this cover letter at the back of the manual to provide a record of changes. 


ny 


“{BM Corporation, Publications, Department 245, Rochester, Minnesota 55901 


© 1BM Corp. 1976 | | | | | Printed in U.S.A. 


This manual presents advanced RPG I! programming topics 
for application programmers and students, who must code 
programs for IBM System/3: 


e Model 6 

@ Model 8 

@ Model 10 (Card System) 
‘@ Model 10 

@ Model 12 

e Model 15 


The System/3 Model 8 is supported by System/3 Model 10 
control programming and program products. The facilities 
described in this publication for the Model 10 are also appli- 
cable to the Model 8, although the Model 8 is not referred 
to. Note that not all devices and features that are available 
on the Model 10, are available on the Model 8. Therefore, 
Model 8 users should be familiar with the contents of the 
/BM System/3 Model 8 Introduction, GC21-5144. 


PREREQUISITES | 


This manual assumes that you have coded and tested some 
basic RPG II programs that include listing records on a 
printer, simple calculations, group totals, and the use of 
more than one record type. You may have gained this 
experience through IBM education courses, programmed 
instruction courses, or previous data processing experience. 
Introduction to RPG 1/1, GC21-7514, contains some of 

this basic information. 
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Preface 


ORGANIZATION OF THE MANUAL 


This publication has eleven chapters. Chapters 1-6 cover 
information that is basic to most data processing jobs: 
RPG II program logic, detailed information about writing 
input, output, and calculation specifications and the con- 
cepts and specifications involved in multifile processing. 
Additional programming topics that you may require for 
your job are presented in Chapters 7-11: controlling input 
and output during calculation time, tables, arrays, data 
structure, and the DEBUG operation. 


RELATED PUBLICATIONS 


There are numerous IBM System/3 publications containing 
further information on RPG II. The following are the re- 
lated reference manuals: - 


@ /BM System/3 Card System RPG I/ Reference Manual, 
$C21-7500 


@ /BM Systemn/3 RPG I! Reference Manual, SC21-7504 
(Model 10, Model 12 and Model 15) 


@ /BM System/3 Model 6 RPG II Reference Manual, 
$C21-7517 


If you are programming on a disk system, it would be help- 
ful if you would understand the disk concepts and disk file 
processing information in the following books before read- 
ing this book: 


© /BM System/3 Disk: Concepts and Planning Guide, 
GC21-7571 


@ /BM System/3 RPG I1 Disk File Processing Programmer's 
Guide, GC21-7566 


This publication is a programmer’s guide; it is not intended 
to serve the same purpose as a reference manual of language 
specifications and does not replace a reference manual. 

RPG II programming topics are approached and organized 
according to their normal use in a data processing job, using 
examples whenever possible. Unlike a reference manual, 
individual chapters are self-contained units of information, 
intended to be read from beginning to end. However, if you 
desire information about a specific topic, you may go 
directly to that topic by using the index or the table of 
contents. If an individual chapter has a special prerequisite 
topic, that topic is clearly identified on the title page of 

the chapter. 


Although the chapters are complete units, there is a logical 
progression of topics through chapters 1-6. Therefore, you 
may wish to read them consecutively. If you have read the 
RPG I! Programming Fundamentals Programmed Instruc- 
tion course, you do not need to read chapters 1-6 consecu- 
tively. 


How To Use The Manual 


For ease of illustration, many of the examples in this book 
use card-like figures to represent records. This does not 
imply that a card device must be used for input or output 
in these situations. Any of several input/output devices 
might be used, depending on which System/3 model and 
configuration you are using. 


Review Questions 


Review questions and answers are provided at the end of 
each chapter. Where chapters contain several related topics, 
these questions are grouped by subtopic. If you wish, you 
may turn to the end of the chapter after you complete each 
subtopic, to answer the review questions and reinforce what 


_ you have learned, before continuing the chapter. 
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Chapter 1. RPG II Logic 


- CHAPTER 1 DESCRIBES: 
Basic RPG II logic. 


RPG II logic related to indicators. 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
Basic three-step logic of a data processing job. 
Detail time and total time. 
- Specific steps in a basic RPG II job that includes detail and total operations. 
RPG I! logic related to the following indicators: 1P, LR, record identifying — 
indicators, field indicators, resulting indicators, halt indicators (H1-H9), overflow . 
indicators (OA-OG, OV), matching records indicator (MR). 
Note: You can use the review questions contained in Review 7 at the end of this 


chapter to test your comprehension of the chapter. Answers follow the review 
questions. : 


RPG If Logic 1-1 


INTRODUCTION 


What procedures do you follow if you are preparing bills to 
send to customers? Before you can do anything you need 
some information. You have to know three things: (1) 
the customer's balance at the beginning of the month; (2) 
his purchases; and (3) his payments. Once you have 
gathered this information, you can perform the necessary 
calculations to find the amount due. Finally you record 
this amount on the bill. You go through these same pro- 
cedures for each customer. 


This is a type of job you can easily have your computer do 
for you. To do the job, however, the computer must know 
the same things you know. You must, therefore, tell it 
exactly what information to expect, what to do with the 
information, and what to give you as a result. This you do 
through specifications you write: File Description; Exten- 
sion; Line Counter; Input; Calculation; and Output-Format. 


To do this billing job, you do things in a logical order. You 
read information first. You do calculations second. Finally, 


as a result of the calculations, you record the amount owed. .. 


Then you begin to do the same things ‘n the same order for 
the next customer. 


The computer must also do things in a logical order. The 
information you supply through specifications doesn’t give 
the computer the logic it needs to do your job; the RPG II 
Compiler supplies this. RPG I logic supplied by the com- 
piler is the framework for your job. When your source pro- 
gram is compiled, your source statements are fitted into the 
framework of RPG II program logic to make a complete 
program. The generated program then has all the informa- 
tion it needs to do your job in a logical manner. 


What happens if, in doing your billing job, you find that a 
customer.paid more than he owed? You know immediately 
that he has a credit balance and indicate so on the invoice. 
How does the RPG I! program recognize this situation? 
And how does it know what to do when such a situation 
occurs? 


The RPG II program uses signals which tell it when a partic- — 


ular situation occurs and what to do when that situation 
does occur. These signals are known as indicators. There 
are many different kinds of indicators which signal many 
different situations. You, as a programmer, must know how 
to specify the indicators so that they signal to the computer 
what you want them to. 


RPG II logic is built around these indicators. Their status 
(on or off) affects the sequence of the program’s operations. 
The logic is set up to test the status of various indicators at 
specific times. By testing indicators, the program knows 


‘what to do next. 


RPG It program logic is designed to take care of all types of 
jobs. You must understand this logic to write specifications 
which make correct use of it. . 


Because the logic is a rather complex topic, it is described 
segment by segment. However, when you have finished 
reading this section, you will have a picture of how the: 
complete RPG II program logic works. . 


BASIC DATA PROCESSING LOGIC 


Usually, all records in a file of input records are not read at 
once. Your computer probably is not large enough to store 
and work with information from all records at the same 
time. Therefore, records are read one at atime. Three 
steps, as shown in Figure 1-1, are done for each record read. 


The phrase program cycle refers to all the operations per- 
formed from the time one record is read until the next rec- 
ord is read.. One program cycle is therefore one revolution 
around the circle used to illustrate the program logic. Since 


one program cycle (one revolution) is needed for each rec- 


ord read, many program cycles are required for every job. 


Consider how the three step logic shown in Figure 1-1 works 
for a job which requires a detailed listing of purchases made 
by each customer. The input file is in ascending order by 
customer number. Each record contains customer name 


~(NAME), number (NUM), and charge (CHRG). Information 


from the record is merely transferred to the printed page. 
One line is printed for each record read. Each record read 
is known as a detail record and each line printed is a detail 
line. 


The job begins: the first record is read. No calculations are 
performed. A record is then printed. This ends the first pro- 
gram cycle. The second begins with the reading of another 
record. Figure 1-2 shows the input and output of the detail 
printing job. 


Suppose, however, instead of merely listing the charges 
made by each customer you also wish to find the total 
charges for each customer, as shown in Figure 1-3. 
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Figure 1-2. Detail Printing Job 


1645 JOE AARON 643 


1645 JOE AARON 742 


Input file 





1796 JOHN BART 2493 


1762 BILL BELL 13142 


6.43 


131.42 © 


Write or punch 


results 


Printed report 





. Read a record 


Perform calculations 





JOE AARON 
JOE AARON 


BILL BELL 


JOHN BART 
JOHN BART 


Figure 1-3. Calculating and Printing Totals - 
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To do this, you must do calculations to accumulate a total 
in addition to printing out individual (detail) records. But 
when do you print out the total you have calculated? The 
total for a customer, of course, should be printed after all 
detail records for that customer have been printed (Figure 
1-3). However, in the three-step logic discussed so far, there 
is no provision for printing a total record. Neither is there 

a way to distinguish between individual input records in 
order to determine when all records for a customer have 
been read. 


If the RPG II program used only the three-step logic, it 
would not be able to do this job and many others like it. 
It could adequately work with information from only one 
record at a time, as in the detail printing job. It could not 
correctly do operations to accumulate data from several 
records. 


e 
Perform detail 
output operations 






time 
Perform detail 


calculations 


e Perform total 
output operations 


Figure 1-4. Basic RPG 11 Logic 
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BASIC RPG II LOGIC 


RPG II logic, therefore, is an extended version of this 3-step- 
logic. It calls for calculations and output operations to be 
done at two different times in one program cycle (see Fig- 
ure 1-4). The names detai/ and tota/ have been given to the 
times at which calculation and output operations are per- 
formed. Total time, as the name suggests, is the time in 
which total operations are done on data accumulated from 
a group of related records. The printing of total charges for 
Joe Aaron (Figure 1-3) is an example of a total time opera- 
tion. Detail time is the time in which operations are per- 
formed for individual records. An example of a detail time 
operation is the printing of an individual charge for Joe 
Aaron. Remember, detail operations are done for every 
record read, but total operations are done only after a cer- 
tain group of records are read (see Figure 1-5). 
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Figure 1-5. Detail Versus Total Operations 


Because this basic RPG II logic is only a framework for your 
job, you have to supply additional information so that your 
job will be complete. Only then will your program work 
correctly. For example, the RPG I! compiler supplies your 
program with the logic framework which enables it to do 
detail and total operations. But you must tell it when total 
operations should be done and which calculation and output 
operations are to be done at detail time and which are to be 
done at total time. 


Remember that the only way you can tell the program | 
what to do in certain situations is to use indicators. Con- 
trol level indicators are used to tell the program: 

1. When to do total operations. 

2. What operations are total operations. 

If you were finding total monthly charges for each cus- 


tomer, how would you know when to record totals for 
each customer? When you encounter a record with a dif- 
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all records in 

one group have 
been processed. 
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ferent customer number in the NUM field, you know that 
you have gathered all the information for one customer. 
(You could use the NAME field to tell you this, but there 
is achance that two customers may have the same name.) 
You would then record that total before gathering infor- 
mation for the next customer. 


Any field used to control and direct processing is known 

as acontrol field. You indicate to the compiler program 
which field is a control field by assigning one of the control 
level indicators (L1-L9) to the field in columns 59-60 of 
the Input sheet. You also use this same control level indi- 
cator to tell the program which calculations are total calcu- 
lations by entering the indicator in columns 7-8 of the 
Calculation sheet. Those calculations that are not con- 
ditioned by a control level indicator (in columns 7-8) are 
detail calculations. Control level indicators are not used 

in the Output-Format sheet to indicate detail and total 
records. Rather a T is used in column 15 to indicate a 
total output operation; and H or D is used to indicate 

an operation done at detail time. - 
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Specific Steps in Basic RPG II Logic 


Figure 1-4 shows very generally the sequence of events in an 
RPG II program cycle. The RPG II logic actually consists 
of definite steps taken during the cycle. When you do a job 
you mentally ask yourself questions such as, ‘Do | do this 
now? Do | have all my information? What should | do 
next?”’ RPG II logic also asks questions. It uses your pro- 
gram to find the answer and thus determines what to do 
next. The questions, and specific steps taken based on the 
answers to the questions, are shown in Figure 1-6. _ 
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Figure 1-6. Steps in RPG I Total and Detail-Time Logic 
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time 


‘According to RPG II logic, after a record is read the program 


checks to see if information in the control field of the record 
just selected is different from the control field information 
in the previous record. (The program always saves the con- 
trol field information so that it can make a comparison.) If 
there is a change, the proper control level indicator (the one 
you assigned) is turned on. This means that all records 

from one group have been read. All total operations can 
then be performed. Control level indicators are always 
turned off before the next record is read. 
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Notice the step between total and detail time. Here data 
from the record read at the beginning of the cycle is moved 
into a processing area and becomes available to use in cal- 
culations and output. Data from this record is not available 


at total time. Total operations are performed only on data 


accumulated from previous records. Detail operations on 
the record which caused the control level indicator to be 
turned on are done only after total operations for previous 
records. 


Why are total operations done before detail operations? 
Think of what would happen if the record which caused 
the control level indicators to be turned on were processed. 


Information on this record would be added to information _ 


from records in the previous group. Asa result, the totals 
printed would be in error since they contained information 
from one record in the next group (the record just read). 

To prevent data from the first record in anew control gropp 
from being accumulated in the totals for the previous 

group, total operations are done before detail operations. 


First Program Cycle 


When control fields are specified for a record, the first pro- 
gram cycle may be slightly different from the others. 


Control level indicators are turned on by the first record 
containing control fields. This happens because contents 
of the control fields on this record are different from the 
blank control field areas that were in main storage before 
the record was read. To prevent printing of blank totals on 
the first cycle, RPG II logic causes total operations to be 
bypassed on the first cycle. 


Note: \f the initial input records do not contain a control 
field, total calculations and total output operations are 
bypassed on each program cycle through and including the 
first cycle in which a record with control fields is read. 


Summary of Basic RPG II! Logic 


Figure 1-7 shows specifications for the group printing job . 
previously discussed and the logic for the first four pro- 
gram cycles. Follow the logic involved in each program 
cycle step by step. Remember, the cycle repeats itself from 
the time the program is started until the last record is 
processed. 


Be sure you understand this basic logic before proceeding 


further. , 


RPG I] LOGIC RELATED TO INDICATORS 


It was previously stated that RPG II logic is built around 
indicators. This section discusses how logic related to in- 
dicators fits into the basic RPG I! detail and total time 
logic shown in Figure 1-4. 


In your specifications, you use indicators to tell the pro- 
gram what to do and when to do it. Although you use in- 
dicators, you do not set them. Naturally the indicators 
don’t turn on and off by themselves. The compiler supplies 


logic which is needed to control the setting of indicators. 


Indicators are set to signal various conditions that occur 


- during the execution of a program. In addition to setting 


indicators, RPG II logic also causes tests to be made for 
various indicators at certain times in the program cycle. 
Specific operations are performed as a result of these tests. 


It is very easy to think that an indicator is on when it really 
is off or vice versa. It is extremely important that you know 
when indicators are on and when they are off in the pro- 
gram cycle. Many programs fail just because the program- 
mer did not understand RPG II logic concerning indicators. 


_- The following paragraphs will discuss the time in the pro- 


gram cycle at which indicators are set and the time at 


which they. are tested. 
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Figure 1-7 (Part 1 of 5). tHlustration of Detail and Total Time 
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Figure 1-7 (Part 4 of 5). Illustration of Detail and Total Time 
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1P (First Page) Indicators 


It was stated before that the first program cycle is slightly 
different from the others because total operations are by- 
passed on the first cycle. Another difference in the first 
cycle is that the first page indicator (1P) is on during the 
beginning of the cycle. Any records conditioned by the 1P 
indicator are printed before the first record is read. 


This indicator is used to condition records which are to be 
printed on the first page of a report. These records are 
usually headings used to identify information found on the 
page, but may also be detail lines. 
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Figure 1-8. Logic for the First Page (1P) Indicator 





The 1P indicator is turned on only for the beginning of the 
first cycle. It is turned off before a record is read and is 
never used again during the program (see Figure 1-8). 


Notice in Figure 1-8 that the program performs 1P output. 
and other heading and detail output first when it is started. 
This is always true. \n any program, 1P output and any 
other heading or detail output for which specified condi- 
tions have been met is performed before the first record is 
read. On succeeding cycles, however, it is usually easier to 
think of reading a record as the first step in the cycle. 
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Assume that a heading is desired on the report created by . 
| the previous example (Figure 1-7). The heading should be 


printed on the first page before any records are printed. 


Thus the heading line is conditioned by 1P (see Figure 1-9). 


Figure 1-10 shows what happens in the first cycle according 


to RPG II logic. 
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Figure 1-10. Program Cycle Illustrating the 1P Indicator 
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Last Record Indicator (LR) 


The last program cycle is also a little different from the 
others. When the record with a /* in positions 1 and 2 is 
read, the LR (last record) indicator is turned on. Since the 
/* record has no data on it, detail operations need not be 
performed. Thus RPG I! logic is set up so that detail 
operations are not done when LR is on (see Vote). Total 
Operations are done. The program then ends. 


When the last record indicator is turned on, all control level 
indicators are also turned on. Thus all total operations con- 
ditioned by L1-L9 and LR are performed. See Figure 1-11 
for specific steps in the end of job logic. 
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Figure 1-11. Logic for the Last Record (LR) irfticator 


You use LR to condition all operations done at the end of 
the job. These usually include the calculating of totals for 
all records and/or writing or punching summary informa- 
tion. Suppose the previous example (Figure 1-7), which 
found total charges for each customer, required the state- 
ment List Complete as of (date job was run). 
Since this is to print out after all records have been 
processed, it is conditioned by LR (see Figure 1-12). | 
Figure 1-13 shows what happens during the last program 
cycle according to RPG II logic. 





Note: Detail operations are done if LR has been turned on 
during calculations, rather than by reading a /* record. 
However, when LR is turned on in calculations, the other 
control level indicators are not turned on. 











e 
@ 
Reada 
record 
Was the record 
just read an end 
of file ( / * ) record? 
e@ 
@ 
e 
If so turn 
on all control 
level indicators 
and LR e 
Perform 
total 
calculations 





RPG OUTPUT SPECIFICATIONS et ees Se 


; Printed in U.S.A. 
IBM International Business Machine Corporation 


1 2 75 76 77 78 79 80 
Program Punching | crmric | | | | | f J | Card Electro Number ; Pisani 
ee ee) eee ce Lo rn 























Output Indicators 


A 
ye | 
A 
eke 19 20/21 7 
_ 2 


X = Remove 
Plus Sign 
Y = Date 
Field Edit 
Z = Zero 
Suppress 





Zero Balances 
cme [Pri [nese [on | I 
Field Name yes Yes 
Yes 
















Filename €nd 


Positon 
in 
Output 
Record 





Type (H/D/T/E) 
Stacker # /Fetch(F) 















Before 
After 


Constant or Edit Word 
*AUTO 


B/A/C/1-9/R 




















39 46 47 48 49 50 51 52 neal 57 58 59 60 61 62 63 64 65 66 67 68 69 70}71 72 73 74 
te : | Bg TE aan Pee 
4.4 
+H rib aH Pid HEHE 
oak fei) 
j a 
ay rte Ce 
i IL El AS OF’ | 
’ ' 
Loa sg 
in | | plat Lt a fae 
HH HT | PLCC eer 
ag > i 7 
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Figure 1-13. Program Cycle Illustrating the LR Indicator 


Last 
cycle 


Perform 
total 
calculations 





Was the record 


just read an 
end of file 
(/*) record? 


If so turn 

on all control 
level indicators 
and LR ° 






Record Identifying Indicators (01-99). as : ae . After the program has selected the next record to process, 
it turns on the record identifying indicator which you as- 


~ You assign a record identifying indicator to each type of signed to that record type. This indicator is turned off only 
record in the input-file. If certain ‘operations are to be per- at the end of each program cycle; thus it is on during both 
formed for one record type only, you: may condition those ’ detail and total operations. Detail and total operations con- 
operations by the appropriate record identifying indicator. ditioned by the record identifying indicator, currently on, 
By this method you can tell the RPG I! program what oper- will then be performed. 


ations to perform when it‘processes a specific record type. 
§ =e - Figure 1-14 shows specific steps in the RPG II logic related 


to record identifying indicators. 
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Figure 1-14. Logic for Record Identifying Indicators 
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Consider the use of record identifying indicators in a billing 
job. A monthly file is kept which contains records of pur- 
chases and payments made by each customer. In addition, 
the file contains a balance forward record for each cus- 
tomer. Figure 1-15 shows the three input record nee used 
and output records required. 
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Figure 1-15. Input and Output for Billing Job 


The three record types are defined on the input sheet. Each 
type is given a different record identifying indicator. The 
record identifying indicators are then used to indicate which 
operations are to be performed for each record type. Fig- 
ure 1-16 shows the input, calculation, and output-format | 
specifications for the job. Use these-specifications to help 


- you follow, step by step, the operations Puen in the 


program cycles shown in Figure 1-17. 
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Figure 1-17 (Part 1 of 3). Program Cycle Illustrating Use of Record Identifying Indicators 
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Figure 1-17 (Part 3 of 3). Program Cycle Illustrating Use of Record identifying Indicators 
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Field Indicators (01-99) 


Field indicators are used to test a field on an input record 
fora plus, minus, zero or blank value. Any operations 
that are to be performed only when a numeric field is plus, 
minus, or zero or when an alphameric field is blank may 
be conditioned by the appropriate field indicator. 


Note: A numeric field that is all blanks will turn on an 
indicator specified for all zeros. However, if an alphameric 
field is all zeros, the field will not turn on an indicator 
specified for all blanks. 


Field indicators are turned on or off after data from the 
record to be processed has been moved into the processing 
area. Figure 1-18 shows the RPG II logic related to field 
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For each program cycle, field indicators are set to reflect 
the result of the test on a field. If the condition tested for 
is satisfied, they are turned on; if the condition is not satis- 
fied, they are turned off. A field indicator that is set as 
the result of a test retains its setting until another test is 
made using the same indicator. | 


When the indicator is on, any detail and total operations 
conditioned by the field indicator may be performed before 
testing of a field again resets the indicator. Remember that 
at total time, however, the field indicator will have the set- 
ting established in the previous cycle. 
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Consider the use of field indicators in the billing job pre- Each time a record with a B in position 96 is read, DISCRT 


viously described. The same record types are used as in the must be tested. Only when it contains a positive value 
previous job. The only difference is the additional field, ° should discount be calculated. Figure 1-19 shows the input, 


discount (DISCRT), in columns 39-40 on the balance for- calculation, and output-format specifications for this job. 
ward record. — ney oe . ; 
Use these specifications to help you follow, step by step, 
All employees receive a discount on everything they buy. _ the logic for each program cycle shown in Figure 1-20. 
The rate of discount they receive is recorded in the DISCRT 

field. All accounts other than employee accounts have a 

zero in the discount field since they receive no discount. 
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Figure 1-19 (Part 1 of 2). Billing Job Specifications Using Field Indicators 
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Figure 1-20 (Part 3 of 3). Program Cycles Illustrating Use of Field Indicators 
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Resulting Indicators (01-99) 


Resulting indicators are assigned to signal something about 
the result of a calculation operation. Any operation which 
is dependent upon the result of the calculation can then be 
conditioned by a resulting indicator. 


Resulting indicators may be turned on or off at either de- 
tail or total calculation time. An indicator which is set as a 
result of the calculation operation retains this setting until 
the next time a calculation is done for which the same in- 
dicator is a resulting indicator and the condition is not 
satisfied. Figure 1-21 shows the RPG I! logic related to re- 
sulting indicators. . 
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Figure 1-21. Logic for Resulting Indicators 
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A resulting indicator may change status in the same cycle. 
This happens when one indicator is assigned to signal the 
result of both a total and detail calculation. The total cal- 
culation could turn it off and the detail calculation could 
turn it on, or vice versa. The indicator will not, however, 
be reset to show that a field is blank or zero after being 
blanked out by the Blank After function (B in column 39 


' of the Output-Format sheet). 


The use of resulting indicators is demonstrated by an inven- 
tory job which determines whether an item needs to be re- 
ordered. After inventory has been taken, the quantity on 
hand is recorded for each item. If the quantity on hand is 
100 or less, reorder should be immediate. If the quantity 
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is over 100, the item need not be reordered at this time. A 

list of all items is printed. All items to be reordered are in- 

dicated with a double asterisk. Figure 1-22 shows the 

specifications for the job. Use these specifications to help . 
you follow the program cycles shown in Figure 1-23. , 
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Figure 1-23 (Part 2 of 2). Program Cycles Illustrating Use of Resulting Indicators 
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Halt Indicators (H1-H9) 


Halt indicators are used to stop the program when a speci- 
fied condition is satisfied. Halt indicators may be used as 
record identifying, field, or resulting indicators. When halt 
indicators are used as record identifying indicators, a halt 
will be caused by a specific type of record; when used as 
field indicators, a halt will be caused by erroneous input 
data; when used as resulting indicators, a halt will be caused 
by erroneous results from calculations. 
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Figure 1-24. Logic for Halt Indicators 
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A halt indicator may be turned on at one of four different 
times (see Figure 1-24). Its use, of course, will determine 
when it is turned on. The program does not halt immedi- 
ately when a halt indicator is turned on. All total and detail 
operations remaining in the cycle are performed first; then 
the program halts. This means that processing will still be _ 
completed on information from the record that caused the 
error condition. 
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After a halt you may continue processing by pressing 
START on the processing unit. Halt indicators are always ~ 
turned off before another program cycle begins. 


Suppose a halt indicator were used in the billing job pre- 
viously described in the discussion of field indicators. The 
halt indicator is used as a field indicator to check for an 
erro in the input record. When recording information for 
a customer who makes many purchases and payments, the 


NUM field is sometimes inadvertently omitted from the 
record. Any record with a blank NUM field should be 
corrected. Therefore, you must have some way of telling 

| the computer to halt if the NUM field is blank. The indi- 
cator'H1 in columns 69-70 (see Figure 1-25) will do this. 
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Figure 1-26 shows the three program cycles. In the first 
cycle there is no error. In the second, a halt occurs because 
of a blank number field. The third begins with another 
record being read. 
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Figure 1-26 (Part 1 of 3). Program Cycles illustrating Use of Halt Indicators 
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The second cycle shows that operations are performed on 
the record that contains the blank NUM field. The record 
} containing an amount of 742 has a blank account number 
field. Thus it is not known whether this record really be- 
longs to Joe Aaron. But Joe is charged 742, regardless, 
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since detail operations are performed before the halt occurs. 
in order to prevent processing data which could be in error, 
you must write specifications which will bypass operations 
when an error occurs. This will be discussed later in the 
chapter titled Controlling Operations in an RPG I/ Program. 
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Figure 1-26 (Part 2 of 3). Program Cycles Illustrating Use of Halt Indicators 
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Figure 1-26 (Part 3 of 3). Program Cycles Illustrating Use of Halt Indicators 
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Overflow Indicator (OA-OG, OV) 


Overflow indicators are used to signal when the end of a 
printed page has been reached. They are assigned to the 
printer file and turn on when the overflow line is printed. 
This could be either at detail or total output time. Those 
lines which you wish to print at the end of one page or at 
the beginning of another are conditioned by the overflow 
indicator. 
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Figure 1-27. Logic for Overflow Indicators 


Figure 1-27 shows RPG II logic related to overflow indica- 
tors. A more detailed discussion of the purpose and use of 
overflow indicators can be found in the chapter titled Con- 
trolling Printer Output. — | 
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Matching Records Indicator (MR) 


Thus far, you have been concerned with only one input file. 
According to RPG II logic discussed so far, a record is read 
from the input file, then processed. Another is read and 
processed and so on. Suppose you have more than one in- 
put file; from which file is a record read? . 


RPG II logic has been designed so that your program can 
select the next record for processing. Figure 1-28 shows 
general steps in the logic (multifile logic) required when 
more than one input file is used. 
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Figure 1-28. Simplified Matching Record Logic 
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The matching record indicator (MR) is used only when you 
are processing more than one input file. It indicates when _ 
fields on records from different files match. MR is set only 
after total operations are performed. Thus, at detail time, 
MR always signals the matching status of the record just 
selected for processing; at total time, it reflects the matching 
status of the previous record. 


Specific steps in the multi-file logic are described in the 
chapter titled Match Fields and Multifile Processing. At 
this time, it is sufficient to know at what point in the pro- 
gram cycle records are selected for processing and at what 
point MR is turned on. 


Multi-file logic: logic 
used to select the 
record to process 
when more than one 
input file is used. 
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Setting Indicators 


You have just seen the normal setting of indicators accord- 
ing to RPG {I logic. You, in your program, can alter this 
setting by turning any indicator (except 1P) on or off 
through use of the operation codes SETON and SETOF 
(see Figure 1-29). An indicator may be set during either 
detail or total time. !t will be set at the time the SETON 
or SETOF code is executed and will retain the setting you 


give it until it is reset according to the program logic. 
(Refer to the logic for the various indicators, earlier in this . 


section, to determine when they are set on and off in the 


logic cycle.) 
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Figure 1-29. Setting Indicators 


RPG CALCULATION SPECIFICATIONS 


fee TT vie 
a 





Factor 1 Operation Factor 2 





Indicators of various types may be used anywhere in the 
program. For example, you can use LR as a record identi- 
fying indicator, L1-L9 as resulting indicators, or L1-L9 as 
record identifying indicators. If you need to set indicators 
yourself, you should be thoroughly familiar with RPG 1 
program logic so that you will use the indicators correctly 
in your program. 
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Review 1 


Arrange the following steps in the order they occur in the RPG II logic cycle start- - 

ing with Read a record. 

a. Read a record 

b. Total output 

c. Move data from input area to processing area 4 iv : - 
d. Detail calculations 

e. Detail output 

f. Total calculations 


In the RPG I! cycle, total calculations and total output are for data from: 
a. the record just read 

b. records read in previous RPG II cycles 

When is the 1P indicator on? When is it turned off? 


Which steps are bypassed during the first program cycle? 


When the LR indicator comes on, the last program cycle ends after __.____; 
therefore _______operations are not performed when LR is on (/* record read). 


When are record identifying indicators turned on? When are they turned off? 


When are field indicators (the indicators which test the contents of an input field) 
turned on or off? 


Halt indicators may be turned on at various times depending on how they are used. 
If a halt indicator is turned on, when does the computer stop?: 


Calculation resulting indicators are turned on during total or detail calculations. 
When are they turned off? 


Review 1 1-45 
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a, f,b,c,d,e . 


b 


1P is on at the beginning of the first program cycle only. It is turned off before 
the first record is read. | 


total calculations and total output 
total output, detail. 


Record identifying indicators are turned on right after a record has been read and 


identified. They are turned off at the end of each RPG II cycle. 


Field indicators are set just after data is moved from the input area to the proces- 


sing area. 
The computer halts after detail output. 


Resulting indicators remain on until reset by another calculation. 


Chapter 2. Describing and Using Input 


CHAPTER 2 DESCRIBES: 
Specifying and using control fields and split control fields. 
Checking the sequence of record types. 
Describing input record types using the OR relationship. 
OR records with field record relation. 
Field record relation with control fields. 


Conditioning use of input files. 


BEFORE READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
Function and coding of input fields on the Input sheet. 
Function of RPG II indicators. 


RPG II object program cycle (Chapter 1). 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
Function and RPG II coding for control fields and split control fields. 
How to handle typical record type sequence checking situations. 
Function and RPG II coding for field record relation. 
Uses for conditioning input files. 
Setting external indicators. 
Note: You can use the review questions contained in Review 2 at the end of this chapter 


to test your comprehension of the topics in the chapter. Answers follow the review 
questions. 


Describing And Using Input 2-1 


INTRODUCTION 


For every RPG II program, you must describe the input 
information you are processing. This includes describing 
input files, record types within each file, and fields within 
each record type. Input files are described on the File 
Description sheet; record types and fields within each input 
file are described on the Input sheet. 

{ 
From previous instruction, reading, and experience, you 
should already know how to describe and use input files, 
record types, and fields. You should also know how to use 
RPG II indicators to condition operations. This chapter 
describes additional ways to use input with control level 
indicators, field record relation indicators, and external 
indicators. 


CONTROL FIELDS 


A basic type of report in any data processing installation is 
a detail list that consists of one line of printing for each 
record read, such as a transaction listing. Figure 2-1 shows 
what a detail report would look like. 


Because product classes are repeated for each line, the 
report is cluttered and hard to read. The same report (Fig- 
ure 2-2) grouped by class is much easier to read. Here, all 
items from one class are listed together with headings used 
on each page to identify the information. Since all items 
on one page apply to the same class, the class is printed 
only once. Such a report is sometimes referred to as a 
group-indicated report. Group-indication is the printing of 
control information on one line per group. The date is 
printed at the bottom. 


2-2 


A control field is any field used to indicate when a certain 
type of processing should be done. Since the CLASS field 
(Figure 2-3) controls processing, it must be specified as 

the control field. Each time a record is read, this control 
field is checked for a change in contents (control break). 
When a control break occurs, a different type of processing 
or additional processing is to occur. In this case, a change 


_in the CLASS field indicates: _ 


1. Skip to the bottom of the page. 
2. Print the date. 
3. Skip to a new page. 


4. Print heading. 


ITEMNO - DESCRIPTION ON HAND 
7657352 
63241B1 


43151CK 


SWEATER, V-NK, SZ 32 10 
SWEATER, V-NK, SZ 34 16 
CARDIGAN, SZ 36 17 


a 
‘ eo 


76738K2 


54321K4 
56422K4 


o 


CARDIGAN, SZ 40 
T-SHIRT, WH, SZ 30 
T-SHIRT; WH, SZ 32. 
57381J4 T-SHIRT, WH, SZ 40 
58324B1 T-SHIRT, WH, SZ 42 


o o 
57421C2 
67341B3 


T-SHIRT, BK, SZ 46 
WOOL SOCKS, BL 10 


IN STOCK AS OF 10/30/70 





Figure 2-1. Printed Report of all Items in Stock 


ITEM NO 


4673251 
63241B1 
43151CK 


‘DESCRIPTION | 


SWEATER, V-NK, SZ 32 
SWEATER, V-NK, SZ 34 
CARDIGAN, SZ 36 


IN STOCK AS OF 10/30/70 


ITEM NO 


54321K4 
56422K4 
57381J4 
5832481 


DESCRIPTION 


T-SHIRT, WH, SZ 30 
T-SHIRT, WH, SZ 32 
T-SHIRT, WH, SZ 40 
T-SHIRT, WH, SZ 42 


IN STOCK AS OF 10/30/70 


) , ‘ITEM NO 


67341B3 
67432B3 


DESCRIPTION 


WOOL SOCKS, BL 10 
WOOL SOCKS, GR 10 


IN STOCK AS OF 10/30/70 





Figure 2-2. Report Group - Indicated by Product Class 
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Figure 2-3. Item Record 
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Coding Control Fields | indicator is used on the Output-Format-Sheet (Figure 2-4, | 
. insert B) to condition those operations which should be 


The RPG II specifications for the program are shown in . performed only when a control! break occurs. Note that the 
Figure 2-4. The entry L1 on line 02 of the Input Sheet __ L1 indicator is used in line 08 to condition the CLASS field 
(Figure 2-4, insert A) establishes the CLASS field as a con- in the detail output line. This causes the CLASS field to be 
trol field. When the information in the control field. printed only for the first record of a new control group. 


changes (a control break occurs) L1 is turned on. The L1 That is, the CLASS field is printed only when it changes. 
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Figure 2-4. Defining and Using a Control Field 
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Split Control Fields 


Two separate parts of a field or two separate fields can be 
used as one control field known as a split control field. 
This is done by assigning the same control level indicator to 
both parts of the field. The compiler will consider the data 
in the split contro! fields as one continuous field. 


Suppose you have a 3-character customer number field in 
the record and now need a 6-character field. The problem 
is how to put a larger customer number (such as 100010, 
100020) in a 3-character field. You cannot change records 
easily because there is no room for expansion on either 
side of the customer number field (Figure 2-5), and to ex- 
pand the field, the entire record format would have to be 
changed. All programs using these records would also have 
to be changed to accommodate the changed record format. 
This would be considerable work and inconvenience. RPG 
I! provides the split control field feature to meet changing 
data processing needs with minimum effort. 





1213 © = 32 33 


Figure 2-5. Three Digit Customer Field 


‘CUSTNO ITE MNO- _DESC QTYORD COST i 


The solution to the problem is to add a 3-character portion 
to the customer number field using three columns which 
are not adjacent to the original customer number field 
(Figure 2-6). The original three numerals of the-customer 
number remain in the original field. The three additional 
numbers are put in the new customer number field. 


At the end of each month, a report is produced consisting 
of: 


1. Customer number. 
2.  Adescription of each purchase. 
3. The cost of each purchase. 


4. — The total cost of all purchases. 





37 38 


CNUM2 ITEMNO DESC QTYORD COST CNUM1 —_ 


12 13 32 33 


Figure 2-6. One Customer Number Split into Two Parts 


37 38 44 45 47 48 
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The report is group-indicated as shown in Figure 2-7. 


The customer number determines when totals would be 
printed and thus must be used as a control field. However, 
on each record the customer number is split into two parts 
(two fields). Both must be used in order to get the correct 
customer number (Figure 2-8). 


Coding Split Control Fields 


Split control fields must be described in specification lines 
which follow one another (Figure 2-8, insert A). 


CNUM1, the field in columns 45-47 of the record, must be 
specified on the Input sheet before CNUM2, the field in 
positions 1-3. This is required because the three digits in 
CNUM1 are the first three digits of the customer number. 


Parts of a split control field may be either alphameric or 


numeric. In this example, they were both defined as numer- 


ic (indicated by the entry in column 52). If one of them, 
however, had been defined as numeric and one as alphamer- 
ic, they both are considered numeric by the compiler. 


CUSTOMER 


001249 


HAMMER 


#14 NAILS 
# Q9NAILS 


CHECKING THE SEQUENCE OF RECORD TYPES 


Many data processing jobs require the use of several kinds 
of information. Sometimes, this information must be in a 
special order to produce the correct results. 


Order of Record Types Within a Group 


For example, to do end-of-the-month billing, you need 
several kinds of information. For each account you must 
know: 


1. The balance forward at the beginning of the month. 
2. Payments made during the month. 
3. Purchases made during the month. 


To get the amount due, you subtract payments made from 
the balance forward and then add new purchases to that 
amount. 


Information concerning balance forward, payments, and 
purchases is usually on more than one record. Payments 
are usually recorded as they are received. Purchases are 
recorded as they are made. The balance forward is also 
kept on a separate record. . 


PURCHASES 


ELECTRIC SAW 


PLYWOOD 


- 002024 





Figure 2-7. Report Group Printed by Customer Number 
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Figure 2-8. Using a Split Control Field 
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Thus, to do the billing, three different types of records 

are necessary for each account. Furthermore, these rec- 
ords must be read in a special order. The balance forward 
record must come first. The payment and purchase records 
can be in any order; it makes no difference whether you — 
subtract all payments first, or add all receipts first, or add 
receipts and subtract payments in any order. However, 
you must decide on the order of these records for your. 
program and keep them in that order, since the computer 
will always expect them in a certain order. 


Management of a retail store requires all receipts to be 
listed and subtracted before purchases are listed and added. 
Thus, the order in which the records must be read is: 

1. Balance Forward. 


2. | Payments. 


3. Purchases. 


DOE, JOHN 


DRAKE,A 


DRAKE, A 


Remember that these three types of records are necessary 
for one account. When they are organized, they are organ- 
ized according to account. Each record has a name on it. 
All records with the same name must be grouped together 


"in the file and must be in the order indicated (see Figure 


2-9, part A). : 


_ What if one of the records accidentally got out of order? 


Some customer would end up with the wrong amount. 























DRITT, ED 


~<+——— Payment 
DRAKE, A 
Balance 


DRAKE, A 


DRAKE, A 


~«— Purchase 


Payment 


~~ Balance 


<——_—_————— Purchase 
—_—_ Payment 


~————. Balance 


Figure 2-9. Order of Record Types Within a Group 
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To prevent this, you direct your program to check for rec- 
ord sequence by entries in columns 15-16 on the Input 
sheet. These columns are titled Sequence and are used for 
indicating the sequence of record types for each account. 


These sequence columns are used for every program you 
write. If you are not checking for a special order, these 
columns must contain alphabetic entries. If you are check- 
ing for a special order, these columns must contain numeric 
entries (01-99). 


Since it is first, the Balance record must be given the se- 
quence entry 01 (see Figure 2-10). What sequence entries. 
would the Payment and Purchase records have? Logically, 
they would be 02 and 03 respectively (Figure 2-10). How- 
ever, you could have used 09 and 20. You may use any num- 
bers from 01-99 just as long as the numbers used are in as- 
cending order. However, 01 must always be used. 
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Since there are three different types of records, each should 
be identified by a code so that the computer knows which — 
record type was read. Record identifying indicators should 
be specified for each record type. All fields in each record 
type must also be described. Figure 2-11 shows how the 
‘records kept by the retail store were described. 


How does the entry specifying sequence help you check for 
record sequence? Suppose a payment record was read after 
a purchase record.. This would be incorrect order. The pro- 
gram knows that a 02 record type doesn’t come after a 03 
type and will automatically halt because of the mistake. 


More Than One Record Type Per Group 


What would happen if two payment records (02 record 
type) were read in arow? The program would halt because 
it expects a 03 record type to follow a 02 type. It does not 
expect two 02 types ina row. But what if a customer ac- 
tually made two payments during the month? Or what if 
he bought more than one item during the month? You 
wouldn’t want the program to halt whenever it read more 
‘than one payment of purchase record per customer. 


You must make another entry to indicate whether the pro- 


gram can expect to read one or more records of the same 
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Figure 2-11. Description of Sequenced Record Types 
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RPG INPUT SPECIFICATIONS 


type in one group. This entry is made in column 17 (Num- 
ber) of the Input sheet. A 1 indicates only one record per 
type; an N indicates one or more records per type. In this . 
example, only one balance record is needed. However, 
there may be more than one payment record or purchase 
record. Figure 2-12 shows these entries. 


Optional Record Types in the Group 


It is also possible in this example to have no purchase rec: 
ord. A customer might not have purchased anything during 
the month. If'so, a balance record would be read after a 


payment record for the previous customer (see Figure 2-9,” 


part C). According to the specifications shown, this is 
incorrect order. The program would halt. | : 


~ To prevent halting in this situation, you must make another 


entry, this time in column 18. Place the letter O in column 


- 18 to indicate that the record type is optional (it may or 


may not be present). If you leave column 18 blank, the 
computer assumes that the record type must always. be 


present. 


Of the three record types, which must always be there? _ 


The balance forward record should be present. Leave col- 
umn 18 blank for it. The other two record types are op- - 


tional. Enter the letter O for each (see Figure 2-13). 
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Checking the Order of Record Types in a Group 


In summary, three entries must be made to ensure proper 
checking of the sequence of records in a group. 


1. Columns 15-16 must contain a numeral from 01 
; through 99 that indicates the order in which records 
must be read. _ 


2. Column 17 must contain an entry that indicates 
-whether or not more than one record of a type can 
be expected. A 1 indicates that only one record of 
a type will be accepted. An N indicates that more 
than one.record of a type will be accepted. — . 


3. Column 18 must contain an entry which indicates 
whether or not the record type is optional. The let- 
ter O indicates that the record type is optional. A 


blank indicates that the record type must be present. 


Incorrect Records Within a Group 


The entries for checking the sequence of record types with- 
in a group will determine that the records in groups A and 
B shown in Figure 2-14 are in order. Suppose, however, 
that the payment records for John Hill and A. James were 
mixed up (Figure 2-15). The program using the sequence 
specifications just described would not find this error. The 
record types are still in proper order, but the records them- 
selves are in the wrong groups. To ensure that records are 
in the right group other specifications have to be made. 


HILL, JOHN 


. JAMES, A 


For the end-of-month billing example, the NAME field is 
used as a control field. A change in the NAME field indi- 
cates the end of one group and the start of another. Since 
the balance record is always the first one in a new group, - 
the balance record type should be the only one that causes 
a control break. If the records are mixed up, as shown in 
Figure 2-15, a control break will occur before all records 
of one group have been read. For example, when the 
Arnold James’ payment record is read after a John Hill | - 
balance record, a control break occurs because information 
in the NAME field changes. There should be no control 
break at this time. If there is a control break here, the 
results of the report will be inaccurate. 





~~ Purchase 








[- Payment | 





- Payment 


Balance 


Figure 2-14. Correct Data Records in a Group 
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To prevent this, certain calculation specifications must be 
made. Line 01 of the Calculation sheet shown in Figure 
2-16 shows that indicator H1 is set on. H1 is a halt indica- 
tor. When it is on, processing halts after calculations and 
output operations have been performed for the record just 
read. , 


~«—— Purchase 





—_— Payment 


Balance 
/ 8 


HILL, JOHN Purchase 
Payment 





Balance — 


Figure 2-15. Incorrect Data Records in a Group 
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Figure 2-16. Halting When Incorrect Record if Found in a Group 
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Look at the indicators which condition the SETON opera- 
tion, L1 and NO1. A control break (L1 turns on) caused by 
record type 01 (balance record) is correct. But a control 
break (L1) caused when any other record type (02 or 03) 

is read indicates that a record is in the wrong group. This 

is an error condition. Thus when L1 is on (a control break 
has occurred) with any record identifying indicator other 
than 01 (NO1), the halt indicator H1 is set on to stop proc- 
essing. 


Halting on an error is one way of handling error conditions. 
This method allows you to stop, correct the record in error, 
and start processing over again. This often wastes time since 
you must restart the computer each time an error is found. 
Programming to bypass the error is more often done. This 
will be discussed at a later time. 


Sequenced and Unsequenced Record Types ina Group 


So far we have talked about having records in a group which 
must be in a special sequence. However, you may also have 
records in the group which need not be in any sequence. In 
this case, all records which do not need to be in sequence ~ 
are specified on the Input sheet before those that do. Re- 
member that unsequenced records must have alphabetic 
entries in columns 15-16, and blanks in columns 17-18. 


Unexpected or Unused Records Within a Group 


If the computer reads any record types which are not spec- 
ified, it will halt. Often you may have several record types 
within a file, but the job being done requires the use of only 
a few of the record types. Do you still have to specify 

each type? No, you don’t. But remember each time an un- 
described type is found, the program halts. This could result 
in wasted time. Therefore, to prevent halting and to elimi- 
nate a description of each record type, you specify a catch- 
all indicator in addition to specifying all record types needed 
(see Figure 2-17). 
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According to the specifications.in Figure 2-17, any record 
read which does not have one of the identification codes 
specified, is considered to be record type 99. If no opera- 
tions are conditioned by record identifying indicator 99,- 
none will be done for all records which are considered type 
99. 


You may also use a catch-all indicator specification to pre- 
vent halting when unexpected records (record in wrong 
file, blank record, etc.) are read. Unwanted card records 
are normally stacker selected into a special stacker so that 
they can be removed from the deck at the end of the job. 


Figure 2-18 shows specifications that describe three un- 
sequenced record types used in the program and a catch-all 
indicator which will be assigned to unwanted record types 
found in the file. When records are not in a special order, 
(alphabetic entries in columns 15-16), the catch-all indicator 
is described last with no Record Identification Codes. The 
catch-all indicator turns on if a card is read which can not 
be identified by any of the Be Record Identification 
Codes. 
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Figure 2-18. Unsequenced Record Types with Catch-All Sequence 
enty 


FIELD RECORD RELATION INDICATORS 


You may have some programs which process several dif- 
ferent record types. Two or more record types might con- 
tain identical fields. To eliminate coding these identical 
fields for every record type you may use the OR relation- 
ship which indicates that certain fields are found on all 
record types. Not all fields are identical in different record 
types, however. You must have some way of specifying 
those fields found on only specific record types in the OR 
relationship. Field record relation indicators indicate those 
fields found on only specific record types. 


Field record relation indicators will relate: 
@ A field to a specific record type in the OR relationship. 


@ Control fields and split control fields to a specific record 
type in an OR relationship. 


@ Match fields for more.than one record type (see Match — 
Fields and Multifile Processing). 


OR Relationship 


You can eliminate duplicate coding by using an OR relation- 
ship to describe identical record types. This method also 
reduces the size of the program. 


When using the OR relationship, you need to write the 
names of identical fields from more than one type of rec- 
ord only once on the Input Sheet. OR relationship speci- 
fications indicate that the fields named may be found on 
all of the record types. The following input specifications 
are necessary to set up the OR relationship: 


1. Record identifying indicators (01-99) for each record © 
type. 


2. ‘The letters OR in columns 14-15 for all record types 
other than the first. 


3. Entries describing the record identification code of 
each record type (columns 21-41). 


Describing And Using Input 2-15 


The record identifying codes must be described for a// types 
of records in the file before any fields are described (Figure 
2-19). 


The letters OR are placed before the description of each 
record type except the first. OR indicates that the fields 
listed may be found on all record types. In this example, 
the fields listed may be found on records identified by an 
N, D, or O in column 96. Identical fields are described 
after the entries which establish the OR relationship. 


OR Relationship With Field Record Relation Entries 


In the example of printing a report by product class, all 
record types had identical fields (Figure 2-3). Suppose that 
the information on each record type is organized different- 
ly; the records have some fields which are identical and 
some which are not (Figure 2-20). Now you want to print 
only a description of new items. The record identified by 


an NV is the only one with the DESC field. All record types | 


still have CLASS, ITEMNO, DATE, and ONHAND fields. 


The OR relationship can be used when all fields are not 
identical. In this case, additional entries must be made in 
the field record relation columns (63-64) on the Input 
sheet. The entry consists of any of the record identifying 
indicators (01-99) assigned to a record type specified in the 
OR relationship. The record identifying indicator entered 
in columns 63-64 relates a field to a particular record by 
identifying the record type in which the field is found. 


When columns 63-64 are blank, the fields listed are assumed 
to be found in the positions specified on a// records in the 
OR relationship. When an entry is specified in columns 
63-64, the field is found only on the record type having that 
record identifying indicator. 


To use the OR relationship with field record relation entries 
you must: , 


t Code the specifications describing record types in the 
OR’ relationship (Figure 2-21, lines 02, 03, and 04). 


2. Describe all fields which are identical on all record 
types (Figure 2-21, lines 06, 07, and 08). In this 
- example, the identical fields are CLASS, ITEMNO, 
and DATE. 


3. Specify all fields that are found only on the first rec- 

ord type in the OR relationship, then the second rec- 

ord type, then the third, and so on (Figure 2-21, lines 
10,11, 12, and 13). : 


. In this example, the only fields for the first record type 


which have not been described are DESC and ONHAND. 
For each field, the entry 01 must be made in columns 
63-64. This entry means that DESC and ONHAND are 
found on only the record type 01 identified by an NV in 
column 96. 
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Figure 2-18. Using the OR Relationship to Describe Identical Record Types 
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CLASS ITEMNO ONHAND 





1 5 6 - 12 13 32 33 40 90 95 96 


New Item Record 


4aGOO 


CLASS ITEMNO DATE 


O= 


1 5 6 12 13 20 90 95 96 


Regular Item Record 


Q 
Oo 
0 
m 


CLASS ITEMNO ONHAND 


G= 





1 5 6 12 13 20 90 95 96 


Discontinued Item Record 


Figure 2-20. Record Types with Some Identical Fields 
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Pu Figure 2-21. Field Record Relation 


Describing And Using input 2-17 


The DESC field is related to the record identified by an V 
because this is the only record type having a DESC field. 
ONHAND, however, is found on all. record types. ON- 
HAND must be related to the record having an NV in column 
96 because it is in a different location on this record type. 
The field location of ONHAND must be specified and re- 
lated to the corresponding record type by the record iden- 
tifying indicators (Figure 2-21, line 11). 


Remember that when fields are not identical on all record 
types, the field must be described and related to all record 
types on which it is found. 

All fields relating to only one record type should be entered 
asa group and must be given the same record identifying in- 
dicators in column 63-64. 


If most fields are common, describing the record type with 
field record relation usually reduces the number of specifi- 
cations you must write and the amount of storage necessary 
to hold the instructions. 


Field Record Relation with Control Fields 


Control fields can also be related to a specific record type 
in an OR relationship by field record relation entries. In 
Figure 2-22 the CLASS field is a control field (L1 in col- 
umns 59-60). It is also found on all record types; blanks 
in the columns 63-64 indicate this. However, if a control 
field is found on only one record type, the control field 
must be related to the record type in which it is found by 
an entry in columns 63-64 (Figure 2-22, line 07). 


The number of control fields need not be the same for 
every record in the OR relationship. Regardless of the num- 
ber of control fields per record type, all control fields and 
all other fields related to the same record type should be 
entereu as a group (Figure 2-22, lines 07 and 08). 


Field Record Relation with Split Control Fields 


The rules applying to field record relation with control 


_ fields also apply to field record relation with split control 


fields. In addition, when split control fields are found on 
record types described in an OR relationship used with field 
record relation entries, all portions of the split control field 
must be assigned the same control level indicator and the 
same field record relation entry. This is necessary because 
all parts of a split control field are on the same record rather 
than on two different records. 
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Figure 2-22. Field Record Relation with Control Fields 
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CONDITIONING USE OF INPUT FILES (EXTERNAL 
INDICATORS) 


Thus far, in this chapter, you have read about jobs that 
require the complete processing of all input files specified. 
The following topics will illustrate how you can use RPG II 
to do jobs for which: 


le It is not necessary to process one or more of the files. 


2. It is not necessary to process an entire file. 


SALES ANALYSIS 


ITEMNUMBER AMOUNTSOLD- DATE 
46732 7 09/15/70 
8 09/16/70 
09/17/70 


09/19/70 


09/15/70 
09/16/70 
09/17/70 


09/18/70 


09/19/70 


Figure 2-23. Two Similar Reports from Two Different Jobs 





Using One Program to do More Than One Job 


Have you ever thought how useful it would be if, when 
doing similar jobs, you could use one program to perform 
more than one function? . 


Consider, for example, the following jobs. Two types of 
reports are required each week. One is a sales analysis re- 
port showing what items sold during the week. The second 
is an inventory report showing balance on hand for each 
item in stock. Notice the similarity in the format of the 
reports (Figure 2-23). 


BALANCE FORWARD 


ITEMNUMBER AMOUNTSOLD DATE BALANCE 


46732: (Dob § 99/15/70 
8 09/16/70 
09/17/70 


09/19/70 


09/15/70 


09/16/70 


Describing And Using Input 2-19 


Two files are available: the MASTER file which contains and Multifile Processing. ) When records from both files 


balance forward records for all items in the store; and a match, the number sold is subtracted from the balance on 
transaction file (TRANS) which contains all the weekly — hand. The new balance is then printed on the report 


sales for each item (Figure 2-24). Both files are in ascend- following the list of transactions: 
ing order by item number. - . a | | 
One report requires two files; the other only one. How 


The sales analysis report merely requires a listing of records could you write one program to produce reports which | 
found in the transaction file. : . have such different file requirements? If you had some 
way of telling the program when to expect the use of one 
The inventory report requires that records from two files file and when to expect two files, it could be done. 
be matched. (If you are not familiar with multifile pro- me Y 
cessing using two input files, see the chapter Match Fields This you can do with external indicators. 
Item Number Item Number 






Note; On disk systems, 


MASTER & TRANS 7 35680 
could be disk or 
console files. 
32489 
12369 
00469 
00123 


/ MASTER ‘ \ 
7 FILE \ / 
/ < 
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Figure 2-24. Format of Records Used to Produce Sales Analysis and Balance Forward Reports 
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Wat 


Setting External Indicators 


You are already familiar with several types of indicators . 
used in the RPG II language. These indicators are used to: 


1. Signal the occurrence of a specific condition, such as 
matching records, control break, or last record. . 


2. Control when certain operations should be per- 
formed; such as only when a control break occurs, 
~ or when a specific record type is read. 


Most indicators are set by the program on the basis of the ° 
conditions which occur during the execution of the pro- 
gram. External indicators, however, are set by you prior 
to the execution of the program. You do this in one of the 
following ways, depending on which eyes model you 
have: 


Model 10 Card System: \n order to set external indicators 
in the Card System, enter an Indicator Control Card in the — 


‘System Initialization Program. The contro! card must have 


the following format: 


- Columns Entry 
1-2. [I (two slashes) 
3 blank. 
46 - .. . IND 
ae blank 
8-15 | Bes One-position entries indicating the setting 
of U1 through U8. Indicator U1 is set in 
- column 8, U2: in column 9, and so on, as - 
follows: 
Tt . faticatoe is turned on. 
0. . Indicator is turned off 
(blank) Indicator remains as it 
was set in the last job 
16-96 blank - 


Figure 2-25 shows an Indicator Control: Card which causes 
external indicators U1 and U8 to be set on, indicators U2 

through U6 to be set off, and indicator u7 to remain as it 

was in the previous program. 





Once an indicator is set, it is not changed during the entire 
program. The only way the setting may be changed for the 
next program is by another Indicator Control Card entered 
in the System Initialization Program. 


: 
/ 
\ 


— Indicators set 






— Punches ° 





// IND, 1\GGp9o 17 
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Figure 2-25. Indicator Control Card (Model 10 Card System) 


| Model 10 Disk System and Model 15: Although most 


indicators are set by the program, you set external indicators 
prior to the execution of the program. This is done by 


_ including a SWITCH statement in your Operational Control 


Language. The format of the SWITCH statement is: 


// SWITCH indicator settings |. 


' -The indicator settings are: 


, 


1 = indicator is turned on. 
O = indicator is turned off. 
X = indicator is unaffected, 


Describing And Using Input 2-21 


Figure 2-26 shows a SWITCH statement which sets external 
indicators U1 and U8 on and indicators U2 through U6 off. 
Indicator U7 is unaffected. 


Once an indicator is set, it is not changed until you provide 
another SWITCH statement or perform IPL. You cannot 
use the SETON or SETOF operation codes with external 
indicators. — 


On the Model 15, when operating in job mode, SWITCH 
settings are reset to O at end of job. 


Model 6: The operator sets external indicators prior to 
execution of the program by responding to the SWITCH 
keyword displayed by the system. An eight-position re- 
sponse is possible, corresponding to the eight external in- 
dicators. Possible entries for each position are: 


indicator is turned on. 


1 = 
O = indicator is turned off. 
X = indicator remains unchanged. 


For example, if the operator keys XXXX10XX in response 
to the SWITCH keyword: 


@ Indicator U5 is turned on. 
® Indicator U6 is turned off. 


@ Indicators U1, U2, U3, U4, U7, and U8 remain un- 
changed. 


While displaying the SWITCH keyword, the system displays 
the previous external indicator setting. If all indicators are 

to remain unchanged, the operator responds to SWITCH by 
pressing PROG START. 


Indicators set by the SWITCH keyword retain their settings 
until another SWITCH statement changes them or the next 
IPL occurs. | 





Figure 2-26. SWITCH Control Statement 


~ Using an External Indicator to Condition a File 


You can assign an external indicator to a file. When the in- 
dicator is on, the file is used; when it is off, the file is not 
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used. This then is how you can tell a program when to ex- 
pect one file and when to expect two. Consider again the 
two jobs discussed previously: sales analysis and inventory. 


The TRANS file is needed for both jobs, the MASTER file 
is only needed for the inventory job. Thus, the MASTER 
file is assigned the U1 indicator. You set the indicator on 
for the inventory job (MASTER is used here) and off for 
the sales analysis job (MASTER is not used here). — 


The U1 indicator is assigned to a file on the File Description 
sheet in columns 71-72. Any of the eight external indicators 
(U1-U8) could be used. U1 was arbitrarily chosen for this 
example (Figure 2-27). 


Naturally, the calculations performed and the type of re- 
port written out will depend upon which job is being done. 
Different calculation and output-format specifications are 
needed for each. In order to determine which specifica- 
tions to use for a particular run of the program, calculation 
and output-format:specifications must also be conditioned 
by the external indicator. This topic will be further 
discussed under Controlling Operations in an RPG II Program. 


When writing a program which can do two jobs, be certain 
that the two jobs are very similar. Where the jobs require 
many different calculations and output operations, it would 
be easier to write two different programs than to use ex- 
ternal indicators. 


Ending the Program Before Processing All Files Completely 


When should end-of-job operations take place? The pro- 
gram would normally end after all records have been pro- 
cessed. When you are reading one file, you usually want to 
process all records in that file. Normally, you wouldn’t 
want to process a few records and then end the program 
unless, of course, you found an error condition. The com- 
puter also operates under the assumption that all records 
in the file should be processed before the program ends. 
The LR (last record) indicator which conditions end-of-job 
operations is not turned on until the last record has been 
processed. 


Suppose, however, that you are using two files in your pro- 
gram. The computer assumes that all records in both files 
must be processed before the program ends. If you want. 
the program to end before all records in both files are pro- 
cessed (for example, when the secondary file runs out of 
records), you can specify this. This is done by placing an E 
in column 17 of the File Description sheet for the file which 
will terminate the program. 


- File Description Specification 


File Type Mode of Processing ; : : z ’, File Addition/Unordered 
File Designation ; Length of Key Field or : ‘Extent Exit Number of Tracks 
End of Fil of Record Address Field ' for DAM : for Cylinder Overflow 
oO ile 
; . Name of : 
Record Address Type Symbolic Number of Extents 


Filename Sequence Type of File Device Device Label Exit aan 
File Format : Organization i : ‘ Rewind -: 
or Additional Area Core Index - 


— Key Field | : : Continuation } Continuation Lines | 
engt Starting 


Location 
271 28[ 29 


Labels S/N/E/M 


r| 
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Figure 2-27. Assignment of an External Indicator 


Figure 2-28 shows the File Description sheet used in a 

billing program that is to end when the last record of the 

secondary file has been processed. This is indicated by an . 
) Eincolumn 17. © 


File Description Specification 


File Type Mode of Processing : File Addition/Unordered 
File Designation Length of Key Field or ; Extent Exit Number of Tracks 
. of Record Address Field : a forDAM - .] .| for Cytinder Overflow 
End of File 
> ; Record Address Type F Name of Number of Extents 


Symbolic : 
Filename Type of File Device { Label Exit 
File Format Organization 
or Additional Area Core Index ‘ 


— al . 


Labels S/N/E/M 
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Y Figure 2-28. End-of-Job Specification 
ase 
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-To indicate that the program will end only after all records 
from all files have been processed, you have the option of 
leaving column 17 blank for all input, update, or combined 
files or of placing an E in column 17 for all of these files. 
Figure 2-29 shows both ways of specifying that all files 
must be completely processed before end-of-job. For more 
information concerning end-of-job for programs using more 
than one file, see Match Fields and Multi-file Processing. 


File Description Specification 


Fite Type Mode of Processing 3 ‘ File Addition/Unordered 
File Designation . ~ Length of Key Field or Extent Exit Number of Tracks 
; of Record Address Field : for DAM for Cylinder Overflow 
End of File : : . 
‘ Record Address Type : Name of Number of Extents 


Filename Sequence Type of File i symbole | Label Exit 


File Format hit .| Organization 
or Additional Area 





Note: On disk systems, the files shown here might be on different devices, such as disk or console. 


Figure 2-29. Two Ways of Specifying that All Records in All Files Must be Processed Before the Program Can End 
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ae: 


Review 2 


1. A sales analysis report is to be group-indicated by. salesman number as shown on 
the print chart below (GX20-1776). : ; 


The fields on input file records are arranged as follows: 


Positions . 
1-2 Salesman number (last two digits of the three possible) 
3-8 Amount of sale . 
9-23 Customer name 
30 Salesman number (first digit of the three possible) 
96 1 identifies the record type | 


Fill in the input specifications for this program choosing your own file and field 
names. 


PAGE 
DATE 


Legume Fold back at dotted line. 





LaGeemmes Fold in at dotted fine. I 


NOTE: Dimension: 
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2. 


A large warehouse requires a weekly report showing the quantity of each item in 

stock. Three types of records are found in the file for every item in stock: 

a. In Stock, which records the quantity in stock at the beginning of the week. This 
record must be present, and there can be only one per item. It is identified by a 
Q in column 96. 

b. Receipt, which records the quantity brought into the warehouse. This record is 
optional. There may be several per item. It is identified by an | in column 96. 

c. /ssue, which records the quantity shipped out.of the warehouse. This record is 
optional. There may be several per item. It is identified by an O in column 96. 


ITEMNO 1: DATE | INSTOK 
4 
12.3.4 5 6 7 849 10 11 12 13 1445 t6 17 18 19 20 21°22 23 24 25 26 27 28 29 30 3i 


INSTOCK Record 










ag 
ITEMNO DATE | SHIPIN 
1734567 gts 19 Vi 12 13 rhs 18 17 19-19 20 21122 23 24 25 25 27 28 29 30 31 





- RECEIPT Record 












ITEMNO | DATE OUT. 


1:2.2:-4.5 6 7 BS 30 11 12 13 alts i617 18 19 20 21122 23 2425 26 27 2829301 






ISSUE Record 


The records are grouped according to item number. All records of one item number must 
be in the order listed previously. Using the information given, write the Input specifica- 
tions which are necessary to: | 

a. Check the sequence of the records in each group. | 

b. Prevent halting if unwanted or unused record types are read. 


3. Rewrite the Input specifications shown below using field record relation entries. . 


) | RPG INPUT SPECIFICATIONS oe GX21-9094_U/MO50* 


Printed in U.S.A. 
IBM International Business Machine Corporation 
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tro Numbe: 
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Promarenes jor Instruction | Punch eee de eae : ee 
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Filename Field Name 


Position 
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Control Level {L1-L9) 
Matching Fields or 
Chaining Fields 

Field Record Relation 
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GX21-9094 U/M 050° 
Printed in U.S.A. 
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Filename Field Name 


Option (O)} 

Record Identifying Indicator 
C2 

Decimal Positions 

Matching Fields or 

Chaining Fields 

Field Record Relation 


cf mn) 
a@eMeNol Ich 
4] INAIMie! | | I 
BBIWRISWKD | | 





4. | Towrite an RPG II program which will produce either of two similar reports re- 
quiring the use of one or two input files, you must enter a (an) 
indicator in columns__.tt__of the_____§=—_—_ sheet for the optional file. 


5.  Youare reading two files, NAMADD and TRANSACT. TRANSACT records will 
have a field added to them at output time. The program should stop when the last 
record from TRANSACT has been processed. 


Make the necessary File Description entries for NAMADD and TRANSACT. 


cy 
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RPG INPUT SPECIFICATIONS eres x21 088 Mose 


Printed in U.S.A. 


IBM International Business Machine Corporation 


‘1420 75 76 77 78 79 80. 
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Field Record Relation 


Option (O) 
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The two fields which make up the salesman number should be assigned the same 
control level indicator to indicate that both fields are to be considered as one. 


The split control fields must be specified on two adjacent lines. Since the first 
digit of the salesman number is in position 30, this single digit field should be 
specified before the field containing the last two digits of the number. The 

' program determines the order in which the digits are ‘to be arranged by the order 
in which the fields are specified. . 
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GX21-9094 U/M 050° 
Printed in U.S.A. 


INPUT SPECIFICATIONS 
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mon foe | [1 enn 
wencton Pro TT 1 LTE 


Machine Corporation 


IBM International Business 








75 76 77.78 79 80 
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“| Programmer 
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Any alphabetic sequence entry must be entered first to catch all record types not 


being used for the program. This prevents halting when an unused or unidentified 
record is found in the input file. The three record types being sequence checked 


must be assigned sequence numbers in ascending order with the INSTOK record . 


the RECEIPT record second, and the ISSUE record third. Since there is only 


one INSTOK record per group, a 1 must be entered in column 17. This record 


first, 


must be present so column 18 is left blank. Both of the remaining record types 


require an N in column 17 and an O in column 18. They are optional 


and there 


may be more than one per group. Any record identifying indicators (01-99) you 


choose are correct. 
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‘Because these record types contain common fields, the OR relationship may be used 
to describe them. However, since not all fields are common to all record types, 
field record relation entries must also be used. All common fields-WEEKNO, 
EMPNO, and DEPT—are described first. The NAME field, although found on all 
record types, is in different locations. Thus, it must be related to all record types 
by specifying it and its end position three times and using the record identifying - 
indicator in columns 63-64 to indicate the record type with which it is associated. 
PAYRAT is found in only record type 10. Thus 10 is placed in the Field Record 
Relation columns (63-64). DEDAMT and HRSWKD are related to the record type 
on which they are found in the same way. Remember that all fields related to one 
record type must be grouped together. 


An external indicator (U1-U8); 71-72; File Description. 


File Type 
File Designation 
End of Fite 
Filename Sequence 
File Format 


Record 
Length 


ol7] fe TT ET TT 


cL 


bl O£ 69 89 49 99 99 $9 £9 79 19 


File Description Specification 


Mode of Procassing 
Length of Kay Field or 
of Record Address Field 
Record Address Type 
Type of File 
Organization 
or Additional Area 


Symbolic 
Device 


Key Field 
Starting 
Location 


ze tb 


Labels S/N/E/M 





File Addition/Unordered 


Number of Tracks 
for Cylinder Overflow 


Extent Exit 
for DAM 
Name of 
Label Exit 


Number of Extents 


In the example above, TRANSACT is specified as a combined MFCU file because it 
is to be both read and punched. An E is entered in column 17 for this same file to 
indicate that the program should end when all TRANSACT records have been 


processed. 


If you have a disk system, however, TRANSACT could be a disk update file (U in 
column 15). NAMADD would probably also be a disk file. An E would still be 
entered in column 17 for the TRANSACT file. . 
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Chapter 3. Controlling Printer Output 


CHAPTER 3 DESCRIBES: 
RPG I! overflow and fetch ayeetiow to control page formatting. 
| RPG II fetch overflow object program cycle. | 
Aligning printer forms. 
Editing with edit words. 
: Using the special RPG II word, *PLACE, to print duplicate information. 


- Dual printer files. 


BEFORE READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
The RPG II object program cycle for overflow. 
‘Function of RPG II indicators. 


Using edit codes to punctuate numeric data. 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: | 
RPG II overflow and fetch overflow. 
Effects of fetch overflow on the RPG I object program cycle. 
Aligning printer forms. 
Using edit words. 
*PLACE 


Coding for the Dual Feed Carriage Feature on the IBM 5203 Printer and Sone for 
Dual Feed Tractors on the IBM 2222 Printer. 


Note: You can use the review questions contained in Review 3 at the end of this 
chapter to test your comprehension of each topic in the chapter. Questions are’ 

grouped according to the topic to which they apply. Answers follow the review 

questions. 
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INTRODUCTION 


The most important part of any RPG II program is the 
result—the output. This chapter describes the RPG II cod- 
ing necessary to format and punctuate printed output to 
make it easier to read and understand. Methods aré also 


described for duplicating information on the output record | 


and using dual printer files to print two reports in the same 
program. | 


Using the printer, you can create a report consisting of in- 
dividual lines (records) recorded consecutively on stock 
paper. You may also use it to record information on your 


own preprinted forms, such as on bills, invoices, and checks. 


Regardless of the paper or form you are printing on, you 
are always interested in obtaining a report that is neat and 
readable. This means that the format of the report and 
data on the report must be considered when planning the. 
program. 


RPG II coding for the different printers available on 
System/3 is nearly identical. Differences in coding are 
noted. The available printers are: 


© IBM 5203 Printer (Model 10) 

® IBM 1403 Printer (Model 10 Disk System and Model 15) 
e IBM 5213 Printer (Model 6) 

@ IBM 2222 Printer (Model 6) ee 


USING OVERFLOW AND FETCH OVERFLOW TO 
CONTROL PAGE FORMATTING | 


RPG II performs automatic page formatting. With standard 
66 line forms, it leaves five blank lines at the top of a page 
and six at the bottom. (Six lines are printed per inch; eight 
lines per inch are also possible.) However, automatic page 
formatting may not always meet your needs. If you want 
control! over page formatting, you can use an overflow 
indicator (OA-OG, OV). For instance, assume that at the 
end of every month you prepare an inventory report which 
consists of a list of the quantity of all items in stock by 
product class. Items are listed by product class, and each 
product class should start on a new page (Figure 3-1). 


3-2 


Suppose the heading were to start on line 11 of each page. 
To have an equal margin (ten spaces) on top and bottom, 
line 56 should be the last printed line on the page (assum- 
ing 66 lines per page). For this report, you must use an 
overflow indicator to control page format. 


Overflow Indicators 


Overflow indicators, like other indicators, are used to do 
two things: 


® Signal a certain condition. 
\ 
@ Control when specific operations (including those which 
control page format) are performed. 


For example, in the monthly inventory report, items in 
stock are listed by product class. The report consists of 46 
lines per page (starting line is 11 and ending line 56). Some 
product classes are going to have more than 46 different 
items in stock. For these classes, additional pages (overflow 
pages) are required to list the items. 


Normally, the overflow /ine is the last line you want to 
print on the page. For this report, the overflow line would 
be line 56. When this line is printed, the overflow indicator 
(if one is assigned) is turned on to signal that the last line 


’ you wished printed on the page has been reached. 


When the overflow indicator is on, you know that the over- 
flow line has been reached. At the end of the page, opera- 
tions, such as advancing to a new page (the overflow page) 


and printing headings on the new page, can be performed. 
By assigning and using overflow indicators, you can print 
special lines at the bottom of the page and at the top of the 
new page. Because you do these operations only when the 
overflow indicator is on, you will have to condition these 
operations by the overflow indicator. 


a 


) 


\ 






ITEM NO DESCRIPTION | ON HAND 









46732J1 SWEATER, V-NK, SZ 32 . 10 
63241B1 SWEATER, V-NK, SZ 34 16 
43151CK CARDIGAN, SZ 36 17 







IN STOCK AS OF 10/30/71 Line 56 







mm mr cern mm ee 


CLASS {‘TEMNO DESCRIPTION ON HAND 






54321K4 T-SHIRT, WH, SZ 30 411 
56422K4 T-SHIRT, WH, SZ 32 14 
57381J4 T-SHIRT, WH, SZ 40 15 
58324B1 T-SHIRT, WH, SZ 42 8 








’ Line 56 





IN STOCK AS OF 10/30/71 


cm mcr 





CLASS ITEM NO DESCRIPTION : ON HAND 





Line 11 
00126 67341B3 - WOOL SOCKS,BL10 © . 11 
67432B3 WOOL SOCKS, GR 10 _ 9 






IN STOCK AS OF 10/30/71 Line 56 






(erwmmemrerm emer emma cm 


Figure 3-1. End-of-Month Inventory Report 


Controlling Printer Output 


Line 11 — 


Line 11 | 


3-3 


Specifications for Using Overflow Indicators 

You must specify to the RPG II compiler how reports 
should be printed. To tell it what to do, you make.line - 
counter, file description, and output-format specifications. 


Line Counter Specifications 


Line counter specifications, found on the bottom half of 


the Extension and Line Counter sheet (Figure 3-2), are used 


exclusively for defining the number of lines you want 
printed on each page. 


Every time you use an overflow indicator to control for-: 
matting, you should prepare line counter specifications. 
Otherwise, a page length of 66 lines will be assumed with. 
line 60 as overflow line. . 


Figure 3-3 is a sample Line Counter sheet for the inventory see 


report. Columns 7-14 are for filename. Only a printer file. 


IBM International Busine: 


ss Machine Corporation 


Program 


RPG EXTENSION AND LINE COUNTER SPECIFICATIONS 


- Card Electro Number 
Punching - 
Cn a a 


“name can be used here.. Columns 15- 22 contain the entries 
_ for report formatting: 


e Columns 15-17: Place in these columns the number of 


available lines per page. Your page can contain a max- 
imum of 112 lines. The inventory report uses standard 


“'* 11-inch paper, providing 66 lines per page. 


@ Columns 18-19: Put the letters FL in these columns to 
show that the previous specifications gave form length. 


© Columns 20-22: Enter in these columns the number of 


the overflow line, when you want the overflow indicator 
to be turned on. In the example given, it was 56. You 
can use any number from 1-112. 


@ Columns 23-24: Enter the letters OL in these columns 
_ to show that the previous specification was the overflow 
. line. 


Notice that columns 25-80 are not used. 


Form X21-9091 
Printed in U.S.A. 


75 76 77 78 79 80 
Program 
. Identification 


mL 


Extension Specifications 


Record Sequence of the Chaining File 


Number of the Chaining Field 
: Table or 
Array Name 


To Filename 


From Filename 
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on 
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Filename 


Form Type 
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eee BMHEMS 


Figure 3-2. RPG {1 Extension and Line Counter Specification Sheet 
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et eae Poo eda oe 


Number 





_ Table or 
Array Name 
(Alternating 
Format), 


Comments 


Decimal Positions 
Sequence (A/D} 


P/B/L/R 


a 


Line Counter Specifications 


Filename | - 


7 a 2[63 64/65 66 67468 69;70 71 


Figure 3-3. Line Counter Specifications 





File Description Specifications 


You must assign an overflow indicator to the printer file 
when you want to control the format of printed reports. 
This is done by an entry in columns 33-34 of the File De- 

scription sheet (Figure 3-4). You may choose to enter any 
of the following overflow indicators: OA, OB, OC, OD, OE, 
OF, OG, or OV. The one you choose, however, must be 
used throughout the program. L must also be entered in 
column 339 to indicate that line counter specifications are 
used. 


These two entries indicate to the RPG II compiler that it 
.. should not provide automatic page formatting, but should 
) format according to your specifications. If you do not 
make an entry in columns 33-34 of the File Description . 
sheet for a printer file, an automatic skip to line 1 occurs 
on Oye: 





File Description Specification 
File Type Mode of Processing : File Addition/Unordered 
File Designation Length of Key Field or pate Exit Number of Tracks 
: End of Fil of Record Address Field ; : : ‘or DAM for Cylinder Overflow 
—— Record Address Type Symbolic Name of Number of Extents 
Filename Sequence Type of File Device Device Label Exit 
File Format Organization - é 
or Additional Area ore Index 


Lengt : Starting : 
= Location : K Option Entry 


55 56 57 58 59/60 61 62 63 64 6 


saniasEEOED 
HHH 
pee Te helbes ated 

| Different device names could be used here, 
pee on your system configuration 


CEPA Ee model. The device name for the Modei 6 


CTE re | ae | printer would be TRACTR1. 





3 





Figure 3-4. Assigning an Overflow Indicator to the Printer 
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Output-Format Specifications 


When RPG I! handles overflow, pages are advanced auto- 
matically. When you handle overflow, you must specify | 
that forms should advance. This is done by specifying a 
skip to the first printing line on the page. For the end-of- 
month inventory report (Figure 3-1), this would be a head- 
ing on line 11. Figure 3-5 shows the correct specification 
for forms advancement. Remember to make a skip specifi- 


.. Cation on a line conditioned by the overflow indicator 


(Figure 3-5). if you forget, a continuous listing will be the 
result. 


When the printer reaches the end of a printed page, RPG If 
also allows you to ignore that the end of the page has been 
reached and continue printing. You do this by assigning an 
overflow indicator and never using it to condition output — 
files. Lines will be printed from the top line to the bottom 
line of each page, even over the’ perforation. If you do not 
want this to happen, remember to use an overflow indicator 
to condition the output operations which are to be done 
when the end of the page is reached. 


RPG © OUTPUT 
IBM International Business Machine Corporation 


Program 


ee Be ee Tt 
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Figure 3-5. Specifications for Forms Advancement 
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SPECIFICATIONS: 


, | 
vom Lome | | | |] [mn _ 





Preventing Records From Printing Over the Perforation 


Suppose your program prints several detail and/or total - 


‘records per program cycle as shown in Figure 3-6. In this 


case, the overflow indicator could be turned on: 


1. - When the detail record is printed. 


2. When any one of the total records is printed. 


If overflow occurs when the detail record is printed, all 
total lines will also be printed before forms advance, pro- 
vided a level 3 control break has occurred (L1-L3 are on). 
Remember the specification to skip to the next page is on 
the heading line conditioned by.the overflow indicator. 
This heading line is reached only after total records are 
printed. 


Assume that line 58 was specified as the overflow line for. 
this program. Assume also that the detail record printed on 
the overflow line and that a level 3 control break occurred 
when the next card was read. One page of the report would 
look like that shown in Figure 3-7. Because all total rec- 
ords are printed before overflow is sensed, the last total 
record is printed on the fourth line of the next page. One 
total record was even printed over the perforation. 


What can you a6 to aliminate this situation? You could 
specify the overflow line high enough on the page so that 
all total records would be printed on the page after the 
overflow line has been reached. For the report shown in| 
Figure 3-7, the printing of total records requires 14 lines (in- 
cluding spacing lines). Thus for the case where a detail rec- 
ord is printed on the overflow line, you would have to 
specify line 44 as the overflow line to prevent printing 

past line 58. _ 
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Figure 3-6. ae Total Records Per Cycle. 
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168.17 


755.67 


13,421.67 


Figure 3-7. Printing Over the Perforation 
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Page of GC21-7567-2 
Issued 21 December 1979 


By TNL: GN21-5709 
This is not the best solution, however. Suppose overflow 
was caused by the second total record instead of the detail 
record. Only one more total line would be printed before 
. forms advanced. Much of the page is not used in this case 
since the last line is printed on line 50 (see Figure 3-8). As 
you see, this is a very uneconomical solution since much 
paper can be wasted. 


Fetch Overflow 


RPG II provides you with a better solution for preventing 
printing over the perforation than the one previously dis- 
cussed. This solution uses the RPG II routine known as 
fetch overflow. Fetch overflow specifications allow you to 
alter the basic RPG II overflow logic (see Overflow Indi- 
cator, Chapter 7). You can cause forms to advance at the 
time total or detail records are printed, instead of waiting 


ee mm ee een eis ee i ee eee 


Figure 3-8. Specifying the Overflow Line High on the Page 


for the usual time. Figure 3-9 shows the two additional 
times when operations conditioned by the overflow indi- 
cator may be performed. (Remember that forms advance 
at this time.) 


During the regular program cycle, the RPG 1! program tests 
only once to see if the overflow indicator is on; this occurs 
immediately after total output. By using the fetch over- 
flow specification, you can tell the computer to check if the 
overflow indicator is on before it prints total or detail rec- 
ords. You do this by simply entering an F in column 16 of 
the Output-Format sheet for any detail or total record. 
When an F is encountered, a test is made before that line is 
printed. 


If the overflow indicator is on when the test is made, all 
operations conditioned by the overflow indicator are 
immediately performed. These operations usually include 
forms advancement and the printing of headings. In order 
for the line to be printed, all other indicator conditions 
tested for on the same line as the overflow indicator must 
also be satisfied. 


78.45 
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4,989.72 





13,421.67 
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(total, heading, detail) 
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Turn off control 
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detail calculations or 
detail output 







verflow indicator 






Perform detait output: 
Turn on overflow indi- 
cator if overflow line 
is printed 


Perform detail 
‘calculations 


Move data into 
processing area 


Is overflow indicator on? 
@ If so perform all operations 
conditioned by the overflow 
indicator and turn overflow 
indicator off 
@ 
Perform total output: 
Turn on overflow indi- 
@ cator if overflow line 
is printed 


lf overflow indicator 
is on, perform output 
(total, heading, detail) : 


: conditioned by the 
overflow indicator and 
turn off the overflow 


Figure 3-9. Logic for Fetch Overflow 
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Figure 3-10 shows two fetch overflow specifications (lines 

07 and 09). Consider how these operations are performed. 
When it is time for the specification in line 07 to be done, 

a test is made to see if the overflow indicator is on. If it is 
on, the overflow routine is fetched; this causes the follow- 

ing operations to be performed. 


1. . All total lines conditioned by the overflow indicator 
are printed. 


2. Forms are advanced (provided a skip to a new page 
has been specified in a line conditioned by the over- 
flow indicator). 


3. Heading lines conditioned by the overflow indicator 
are printed. 


4. The overflow indicator is turned off. 
5. The record specified in line 07 is printed. 


Another test is made to see if the overflow indicator is on 
because of the specification (F) in line 09. If line 07 causes 
forms to advance, the overflow indicator would not be on 
at this time. The total record specified in specification line 
09 would be printed normally. 
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Figure 3-10. Fetch Overflow Specifications 
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An F in column 16 causes the 


overflow indicator is on. | | 


However, if the record specified in line 07 were printed on 
the overflow line, the overflow indicator would be on and 
the specification in line 09 would cause the overflow routine 
to be performed. 


Consider again the example as shown in Figure 3-6. When the 
detail line was printed on the overflow line, all total lines 
were also printed before forms advanced. As a result, print- 
ing occurred over the perforation onto the next page 

(Figure 3-7). 


What records should most logically be printed on an over- 
flow page? Your answer is probably all those records that 
printed on or over the perforation. It would indeed be nice 
if all total records could be printed on the next page when 

a detail record was printed on the overflow line (see Figure ~ 
3-11). 


If the program knew before it printed the first total record 
that the overflow line had been reached, forms could be ad- 
vanced before the total records were printed. By specifying 
an F in column 16 of the first total specification, you can 
tell the program to check to see if the overflow indicator is 
on. If it is on at this time, forms will advance before total 
records are printed. Specifying an F in column 16 of the 
first total specifications will cause all total records to be 
printed on an overflow page. 


Would an F for the first total line take care of all situations? 
Suppose that overflow did not occur until the first total rec- 
ord was printed. The remaining total lines, having no fetch 
overflow specification in column 16, would not cause the 
program to check to see if the overflow indicator was on. 
Thus, they would be printed on the same page (Figure 3-12). 
Counting the spaces, this would mean the last print line 
would be eight lines beyond 58 (the overflow line) or on 
line 66. 


If this is feasible for your report, you could allow printing 
on line 66. If not, you could have the overflow indicator 
checked at the second total line. In this case, if the first 
total! line caused the overflow indicator to turn on, the sec- 
ond total line would fetch the overflow routine. Thus, the 
last total records would be printed on the overflow page. 


How.can you determine on which line to place the F that 
will fetch the overflow routine (provided the overflow in- 
dicator is on)? You should study all possible overflow 
situations. By counting spaces and lines, you can calculate 
what would happen if overflow occurred on each detail and 
total line. This is essentially the method used in the previous 
discussion. 


54 JOE BROWN 409.10 


56 78.40 







Overflow 
58 168.17 


erm ees 


755.67 
4,989.72 


13,421.67 


a ee a ef ee 


Figure 3-11. Printing Total Records on the Overflow Page 
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Figure 3-12. Printing on the Last Line on the Page 
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ALIGNING FORMS 


Regardless of the type of printing forms you are using, it is 
always necessary to have the forms aligned so that printing 
is done on the correct line. If printing occurs above or be- 
low the line, your report looks messy and is hard to read. 


How can you be sure the first line will be printed in the 
correct position? You can align the forms in the position 
you feel is correct. But you can never be sure until you try. 
To try the alignment, the program must be executed; a 
record must be printed. Suppose the forms are incorrectly 
aligned, and as a result, the first printing line is incorrectly 
positioned. In this case, you can stop the computer and 
realign the forms so that, hopefully, the second line will be 
correct. This can go on for several tries, however. In the 
meantime, the first few records printed on: the report will 
have been incorrectly aligned. 


RPG II has the facility to print the first line repeatedly until 
forms are aligned properly. This eliminates printing the 
first several lines of a report before correct forms alignment 
is attained. The use of this facility requires two specifica- 
tions: 


1. An output line conditioned by the 1P indicator. 
2. The entry of 1 in column 41 of the control card. 


When these specifications are made, the first line condi- 
tioned by the 1P indicator is printed. All processing then 
stops. The operator has time to reposition the forms if 
necessary. When this is done, the operator has the option 
of having the 1P line printed again or of continuing process- 
ing. This he indicates by specific settings of the console 
switches on the processing unit. (See halt 1P in the /BM 
System/3 Models 8 and 10 Halt Guide, GC21-7540 for a 
complete description of the alignment process.) 


All space and skip entries specified for the 1P line are per- 
formed when forms are being aligned. This should be con- 
sidered in planning for forms alignment. 


if spooling printed output on the Model 15, the 1P forms 
alignment option will be ignored and the user can request 
alignment by means of the OCL PRINTER statement. 


EDITING 


Formatting a printed report is one way of making the re- 
port easy to read and understand. Formatting, however, 
concerns only the spacing and arrangement of data on the 
printed page. It does not concern the data itself. Data 
must also be readable before the report can be understood. 
Editing makes a field readable. , 
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When fields are printed out according to basic specifications 


if 


they appear exactly as they are inside the computer. This is \ 


shown by the following examples: 
Type of Field Field Before Printing Field After Printing 


Alphameric JOHN T SMITH JOHN T SMITH 


Numeric 004765K 004765K 

The alphameric field, when printed, is easy to read and 
understand, but the numeric field is confusing. How should 
it be read? What does the K mean? K is actually a com- 
bination of a digit and the sign of the field. But in this 
form, the reader would have to guess what it says (see | 
Character Structure in Working With Data Structure for 
more information). 


Editing is the means by which data is made more readable 
and understandable. Editing a field means punctuating it 
by removing the sign of the field from the rightmost digit 
and placing it at the end of the field, adding commas, dec- 
imal points, minus signs, dollar signs, or any other constant 
information. | 


Only numeric fields need to be edited before they are 
printed. Notice the difference between the following 
edited and unedited data taken from the same numeric 
amount field: 


004765K 
$476.52CR 


unedited data 
edited data 


The edited amount field is certainly much more precise 
and understandable than the unedited field. 


Methods of Editing 


A field can be edited by two methods: (1) edit codes anu 
(2) edit words. Several different codes are available. Each 
code edits in a slightly different way according to a pre- 
defined pattern. All, however, remove the sign of the field 
so that the rightmost digit will always print as a number. 
(See Character Structure in Working With Data Structure 
for more information.) The Y edit code is used for date 
fields only. 


Figure 3-13 shows the edit pattern for all codes. Choose 
the code which will edit a field the way you want it to 
appear and enter this code in column 38 of the Output- 
Format sheet. 


Print Out On Zero Balance * 


) 


Zero balances for the World Trade format are written in two ways, depending on the entry made in column 21 of the control card 
specifications. 


The X code performs no editing. 


The Y code is used for date fields. It suppresses the leftmost zero only. The Y code edits a three to six digit field according 
to the following pattern: 

nn/n 

nn/nn 

nn/nn/n 

nn/nn/nn 
If a data field of six digits is packed on disk and the Y edit code is used with the data field, an error will occur. To solve this 
problem, move the data field to another field. 





Figure 3-13. Edit Codes 
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For example, if you wish a field called AMOUNT which 
has two decimal positions to be zero suppressed and punc- 
tuated with decimal points and commas (when needed) but 
with no sign, you choose the code that will do this. The 
chart in Figure 3-13 shows that two codes will accomplish 
this—1 and 2. If you wish a zero balance to print, you 
would choose the code 1. If you wanted blanks to print 
when the field is zero, you would use the 2 code. 


Using edit codes is a convenient way of editing. However, 
the codes by themselves can’t do everything you might 
want to do. 


Punctuating With a Dollar Sign 


Suppose you wanted a dollar sign to be printed on the re- 
port for the AMOUNT field. An edit code won't put the 

dollar sign there. You will have to specify this in addition 
to the edit code you are using. 


According to the printer spacing chart (Figure 3-14), the 
AMOUNT field is six characters long. It begins in column 
70 and ends in column 75. However, the minus sign 

would extend the amount field to column 76, as shown 

in Figure 3-15 and Figure 3-16. The dollar sign, if printed, 
should be in column 69. Line 11 in Figure 3-15 shows the 
specification for editing the AMOUNT field by the edit 
code J. This code is used so that negative values will print 
with a minus sign (-) following the field. The dollar sign can 
be specified as a constant ending in column 69 and must be 
specified in line 12, the line following the edit code. 


PAGE 
TERS PER INCH, 6 LINES PER VERTICAL INCH) DATE 


Depending upon its contents, the AMOUNT field, when 
printed out, could fook like any of the following (where 
N is any number): 


$SNNN.NN 
$ NN.NN 
$ N.NN 
$  .NN 


The blanks between the first digit and the dollar sign are 
the result of zero suppression. The dollar sign remains in 
position 69; this is known as a fixed dollar sign. 


Often, it is desirable, as in writing checks, to eliminate these 
empty spaces. There are two ways of doing this: (1) mov- 

ing the dollar sign so that it is always next to the first digit; 
and (2) filling the spaces with asterisks. 


Instead of having blanks between the dollar sign and the 
first digit, you can cause the dollar sign to print next to 
the first digit. In this case, the amount field would look 
like one of the following: 


SNNN.NN 
$SNN.NN 
$N.NN 
$.NN 


A dollar sign that changes positions is known as a floating 
dollar sign. \t is specified by placing the entry ‘$’ in col- 
umns 45-47 on the same specification line as the edit code 
(see Figure 3-16). Remember that the fixed dollar sign was 
specified by placing $ in columns 45-47 of the line fo//ow- 
ing the edit code (Figure 3-15). 
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Figure 3-14. Printer Spacing Seca 
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the line following the edit code. 





Figure 3-15. Fixed Dollar Sign 





RPG OUTPUT _ SPECIFICATIONS GXx21-9000 _ in 060" 
IBM International Business Machine Corporation r 
75 76 77 78 79 80 
row wom [ome | TL rm = 
eve me Loe OT — Sen 









X = Remove 

Plus Sign 
Y = Date 
Zz 








Field Edit 





Line Filename 







Constant or Edit Word 










5 46 47 48 49 50 51 52 53 54 55 56 57 58 59 6O 61 62 63 64 65 66 71 72:73 7. 


4 





24 


Se 
th oc -aciaialee EH 
SALES! IRePoerl’ | TT TTT TT 

EEE IB erica eles Ii) Teese 





rl’ LEE EET Earl 

ES MAN Pe HR 
Terr 

Lt { 

The floating et sign is ee HHH 


by placing ‘$’ in columns 45-47 aaaea 


of the same line as the edit code. 
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Punctuating With Asterisks 


To indicate that asterisks should fill the spaces caused by 
suppression of leading zeros, place the entry ‘*’ in columns 
45-47 of the same specification line as the edit code. Ifa 
dollar sign is to appear before the asterisk, it must be speci- 
fied on the next line. With the specifications shown in Fig- 
ure 3-17, the AMOUNT field, depending upon its contents, 
could look like any of the following: 

$SNNN.NN 

$*NN.NN 

$* *N.NN 

$* * * NN 


Refer to the /BM System/3 RPG I! Reference Manual, 
$C21-7504 for a more detailed explanation and further 
considerations. 


Punctuating With Dashes 


What code would you use for the following job? A report 
listing all employee names, addresses, telephone numbers, 
and social security numbers, is desired. A file is kept on all 
employees. Each record includes one employee name, ad- 
dress, telephone number, and social security number among 
other things. 


The telephone number and social security number are 
entered in the record as one continuous number with no 
dashes. Remember that fields will print out exactly as they 
are recorded. Thus the telephone number will appear as 
2820804. This is rather hard to read. 282-0804 is much 
better. How will you get the dash to appear? 


A dash is a type of punctuation. So some type of editing 
must be done. Can you find a code that will edit this way? 
No, there is none available. 


For this case, you will have to set up your own editing pat- 
tern. An edit word gives a pattern for punctuation. For the 
phone number you need three digits, a dash, and then four 
digits. You specify the edit word in columns 45-70 of the 
Output-Format sheet. The word, like any constant, must 
be enclosed in quotes. Figure 3-18, line 04, shows how the 
telephone number field is edited: three blanks, a dash, and 
four blanks. 


Unless the social security field is also edited, it will print 
out in one long string of numbers, such as 472446357. 
Form the edit word to make the social security number 
read: 472-44-6357. It should look like the edit word 


shown in Figure 3-19, line 05. Notice that a leading 0 
(zero) is included in the edit word in addition to the num- 
ber of places required for the data. This prevents zero sup- 
pression when the SOCSEC field is edited. 
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Figure 3-17. Punctuating with Asterisks 
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Figure 3-18. Edit Word for Telephone Number 
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Figure 3-19. Edit Word for Social Security Number 
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Punctuating by Leaving Blanks RPG OUTPUT _ SPECIFICATIONS 


A company has rather long account numbers. To make 
them easier to read and handle, blanks are left after every 
third digit when the number is printed. 


ndicators 


sents . Field N. 
Is there a code that will insert blanks? No, again you have oe 
End 


to specify your own edit word. In an edit word, blanks in- ele 
dicate where the digits go and ampersands indicate where al soucue 
blanks will go. The account field consists of ten digits. 

The edit word shown in Figure 3-20, insert A, will put 
blanks after every three digits. 


Edit Codes 
P/B/L/R 


Gilt 


lel tL el | 
ST i tester aL 


Punctuating by Adding Constant Information 


For shipping purposes, the catalog department of a depart- 
ment store must know the weight of every item it sells. 
The weight in pounds and ounces is recorded in a 6-digit 
field. The last two digits are ounces, the first four digits 
are pounds. When printed out on a report, the constants 
LBS and OZ must be inserted. Otherwise, the data would 
not be understandable. Again to do this, an edit word is 
needed because no edit code will insert LBS and OZ. 





Figure 3-20. Edit Words 


The printed field is shown on the printer spacing chart in 
Figure 3-21. One space is needed between the digit and 

LBS and between the digit and OZ. Two spaces separate 
pounds from ounces. Remember in the edit word, blanks 
are specified for digits, ampersands are specified for blanks; 
and constant information is inserted where desired. The 
edit word should be as long as the field shown on the printer 
spacing chart. Figure 3-20, insert B, shows the correct edit 
pattern for this field. 
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Figure 3-21. Print Chart (Weight Field) 
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Edit words can do all kinds of editing for you. They can USING *PLACE TO PRINT DUPLICATE INFORMATION 
) even be set up to do the same thing as the edit codes. All : 
you have to do is show where the commas, decimal points, Using *PLACE, you can tell the RPG II! compiler to print 


credit signs, etc. should appear. A zero is used to indicate duplicate information. When you specify *PLACE on the 
where zero suppression stops. For example in Figure 3-20, Output-Format sheet, the fields listed above it will be 
insert C, the 0 shows where zero suppression is to end in printed in a different position on the same line. This elim- 
the WEIGHT field. inates much duplicate coding. 

Edit codes are a faster and more convenient way of editing For example, assume that your distribution firm prepares 
than edit words. Therefore, edit words are normally used _ invoices on their data processing system. The invoice (Fig- 
only when edit codes alone cannot accomplish the job. ure 3-22) sent to each customer consists of two parts: one 


part the customer keeps, the other he tears off and sends 
along with his payment. Many fields are common to both 


Editing and End Position parts of the invoice. For example, NAME and CUSTNO 

. (customer number) are printed on the first line of each part. 
When specifying end positions for fields which are to be All fields in the fourth line of. the report, except for the 
edited, either by edit words or edit codes, be sure to allow description (DESC) fields, and all fields in the total line are 
enough room for the edited field. If the field to be edited found in both parts of the invoice. The second part is al- 
is six characters long on the input record, do not allow only most a duplicate of the first. 


six positions for it on the printed report. By the time the | 
field is edited, it may contain many more characters than 
six. For example, the WEIGHT field which is to be punc- 
tuated with the constants LBS and OZ is only a 6-character 
field on the input card. ‘But when printed out after editing 
it requires 15 spaces. Always specify an end position on - 
the Output-Format sheet (columns 40-43) that takes into 
account the length of the edited field. 


CUSTNO | CUSTNO 


QTY PRICE . AMT QTY PRICE AMT 





) Figure 3-22. Invoice Form 


Controlling Printer Output 3-19 


Figure 3-23 shows the printer spacing chart for the invoice. 
What output-format specifications would you write to print 
fields twice on the same line? You could define the field 
and give the end position for it each time you wanted to 
print the field. Figure 3-24 shows the coding necessary 
using this method. There is an easier way to do this, how- 
ever. This is through the use of *PLACE. 
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Figure 3-23. Printer Spacing Chart for Invoice 
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Figure 3-24. Output-Format Specifications for Invoice (Coding Each Field Twice) 


Specifications for Using *PLACE | A *PLACE specification must not be conditioned by indi- 
cators in columns 23-31. “PLACE is automatically condi- 

*PLACE is a special RPG II function which can be used to tioned by the same indicators that condition the field or 

‘accomplish duplicate printing with less coding. To the RPG fields to be repeated. 

il compiler the specification *PLACE means: Duplicate . 

that part of the line which has been specified and place the 


duplicated information in a different position on the same Formation of Print Lines 

line. *PLACE means a special function is to be performed. 

You should not use this specification as a field name, since When System/3 performs printer output, a whole line is. 

the RPG II compiler will assume you want the preceding printed at once, regardless of how many fields are in that 

field duplicated. When using *PLACE you first define, for line. Before printing, the whole line is moved to an area of 

each record, all the fields which are to be duplicated. Give storage exactly as it is to be printed. Data is placed in this 

the end position for each field as you normally do. Then storage area one field at a time. 

enter the word *PLACE on the line below the fields which 

are to be duplicated. Figure 3-25 shows the entries for the . . The sequence in which data enters the storage area depends 

first detail line of the invoice. on the sequence that field names are specified on the RPG II 
, Output-Format sheet. The first field recorded on the Output- 

The compiler does not know where to print unless you Format sheet is entered first, then the second, etc. Each 

specify an end position on the *PLACE entry. In Figure field is inserted into the storage area according to its end- 

3-25, the end position given for the *PLACE entry was 86. position entry on the Output-Format sheet. If you have 

made conflicting entries in your specifications (for example, 

The *PLACE specification duplicates not only letters but — one field overlapping another) the last field mentioned is 

also blank spaces. It will duplicate all the characters (in- the one that will print in its entirety. 

cluding blanks) from position 1 to the end position speci- : 

fied for a field. These duplicated characters are then placed *PLACE operates in the same way as normal field names. 

so that they end in the end position specified for the The operations associated with *PLACE are performed in 

*PLACE entry. | 7 the sequence *PLACE is specified on the Output-Format 


sheet in relation to other output entries. 


When specifying an end position for the *PLACE entry, 
you must know exactly where you wish the fields to print. 
You must also consider the amount of space needed for 
the printing of a// characters to be duplicated. Always 
specify an end position which allows room for the printing 
of duplicated fields. — 
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Figure 3-25. Output-Format Specifications for First Line of Invoice (Using *PLACE to Print Fields Twice) 
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A. Result of 
field description 
antries 


Figure 3-26. Line Formation (First Line of Invoice) 


Follow the formation of the first line to be printed on the 
invoice. According to the specifications in Figure 3-25, 
the NAME field ends in position 25 and CUSTNO in 36. 
The first part of the line is completed with these specifica- 
tions (Figure 3-26, insert A). Because of the way lines are 
formed, the end position for the *PLACE entry must be at 
least two times the higher end position specified for a field 
that is to be duplicated. This ensures that the last field 
mentioned will not overlap the field preceding. In this case 
the same fields are to be printed again on the second part 
of the same line. Since the end position was 36, the sec- 
ond part of the same line must end at least in position 72 
(two times higher than the end position for the field to be 
duplicated). It is decided they are to end in position 86. 
The second part of the line is formed by the *PLACE entry 
(Figure 3-26, insert B). 


a RPG OUTPUT 
IBM Internationa! Busine 


ss Machine Corporatio: 


Filename’ 











Figure 3-27. Specifications for Fourth Line of Invoice — 


B. Result of *PLACE 
entry 


Using Different Spacing for Duplicated Fields 


The second and third lines of the invoice do not have fields 
to be duplicated. However, the fourth line of the invoice 
requires that all fields be duplicated. Notice that different 
spacing is required for the duplicated fields because a field 
called DESC must be inserted between ITEMNO and OTY. 


Figure 3-27 shows correction specifications. You want to 
start with ITEMNO since it is the first fied. ITEMNO is 
specified as usual; the end position is given. Then *PLACE 
is specified with the correct end position, 50 in this case. 
These specifications cause the line to look like that in Fig- 
ure 3-28, insert A. 
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47535 


47535 


47535 


47535 38 = 1.10 41.80 


WOOL SOCKS, GR, SZ 9 


A. Line after first 


*PLACE 


B. Line after second 


*PLACE 


C. Line after speci- 
fication of the 
DESC field 


Figure 3-28. Fourth Printed Line 


Now, the remaining three fields are specified and an end 
position is given for each. “PLACE is entered after them 
to signify that the above three fields should be duplicated. 
Remember that when fields are duplicated, all information 
from position 1 to the highest end position specified for a 
field is used. In this case, positions 1 through 38 are dupli- 
cated and placed so that they end in position 95. 


QTY, PRICE, and AMOUNT are in positions 1 through 38, 
but ITEMNO is also there since it ends in position 10. Thus, 
all four fields are duplicated and placed so that they end in 
96. Figure 3-28, insert B shows resulting formation of the 
line. ITEMNO now appears three times, once in the DESC 
field area where it should not be. 
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In this example, we can specify the field DESC to end in 
position 75. It will overlay the unwanted ITEMNO field 
and thus get rid of it. Figure 3-28, insert C shows the line 
as it will be printed. 


For each job you do using *PLACE, you will have to cal- 
culate exactly what happens when lines are formed. 


Duplicating Constants 


*PLACE can duplicate constants as well as fields. The same 
specifications are used for both. Figure 3-29 shows the 
specifications for the last line of the invoice. In this case 
*PLACE duplicates a field and two constants. As you can 
see, using “PLACE eliminates duplicate coding. 
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Figure 3-29. Using *PLACE to Duplicate Constants (Last Line of Invoice) 
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Printing a Field Several Times on the Same Line Since the label has to be only a few inches wide, the man- 
~ ager found he could print three labels side by side on his 


*PLACE can be used to print the same field several times in 120-print position printer (Figure 3-30). 

the line. All you have to do is enter *PLACE along with an 

end position for each time you want the fields duplicated. You can see that each field needs to be printed three times 
if you want the field duplicated twice, you need two on each line. In the examples discussed so far, “PLACE was 
*PLACE entries. used to duplicate fields only once. 

Assume that periodically a store prepares mailing labels for ‘Figure 3-31 shows the specifications for the first line. 

each customer who has an account with them. They use NAME needs to be entered three times per line. The orig- 
the labels when they send out special advertisements. The inal field specification prints it one time: the two “PLACE 
mailing label has only name, address, and zip code on it. entries cause it to be printed two more times. ; 


| NAME | | NAME } 
| ADDR j | ADDR } 
| CITY | [STATE | | CITY j [STATE] 


21P ZIP 





Figure 3-30. Mailing Labels 
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| Figure 3-31. Using *PLACE for Producing Mailing Labels 
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USING TWO PRINTER OUTPUT FILES IN ONE 
PROGRAM 


) ‘Two System/3 printers, the IBM 5203 Printer on the Model 
' 10 Card and Disk systems and the IBM 2222 Printer on the 
Model 6 allow you to produce two separate printer output 
files on the same printer in a program (Figures 3-32 and 
3-33). The forms can be narrower than standard forms and 
are often special forms such as checks or invoices. 


A minimum of 17 print positions, between 
the left carriage tractor and the right 
carriage tractor, are not available for printing. 





Figure 3-32. 5203 Printer with the Dual Feed Carriage Feature 7 | 53958A 


Primary tractor 


Secondary tractor 





Figure 3-33. 2222 Printer with Dual Feed Tractors | 54019A 
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Model 10 Card System, Model 10 Disk System, and 
Model 12 


The feature of the 5203 printer that allows you to produce 
two separate printer output files is known as the Dual Feed 
Carriage Feature. The feature is available on 96, 120, and 
132 position printers. One form is controlled by the left 
carriage of the printer and the other form is controlled by 
the right carriage. There is space between the right and left 
carriage tractors that contains no form. When you are print- 
ing on two forms you lose at least 17 print positions 
because no forms can be placed in this space (see Output- 
Format Specifications, later in this section). 


Model 6 


The 2222 printer on the Model 6 has dual tractor feeding, 
a primary tractor and a secondary tractor. All 220 posi- 
tions of the printer are available for printing, that is, there 
need be no positions lost between the primary tractor and 
the secondary tractor. . 


The tractors that control the right-hand and left-hand forms 
on the printer are adjustable. That is, the width of the 
forms and the starting and ending print positions for each 
form are variable. 


on 


To print two output files for one program, each of the two 
printer files is considered a separate output file and must’ 
be described as such. These output files require special 
descriptions on the File Description and.Output-Format 
sheets. 


File Description Specifications 


Model 70 Card System, Model 10 Disk System, and Model 
12: Figure 3-34 is a sample File Description sheet for the 
Dual Feed Carriage Feature. The two output files to be 
printed must be assigned to the device names PRINTER and 
PRINTR2 on the File Description sheet (columns 40-46). 
PRINTER is the device name for the left carriage of the 
printer. The right carriage is assigned the device name 
PRINTR2. Record Length entries (columns 24-27) for the 
two printer files should be the same. Entries under Block 
Length (columns 20-23) must be the same as Record Length 
entries. You are responsible for ensuring that output to the 
PRINTER device is confined to the left-hand form and out- 
put to the PRINTR2 device is confined :to the right-hand 
form. You can easily lay out your two reports using the 
Printer Spacing Chart. 


‘File Description Specification 


Fite Type Mode of Processing 


File Designation 
End of File 


Sequence 


Filename Type of File 


File Format Organization 


or Additional Area 


Length of Key Field or 
of Record Address Field 


Record Address Type 





File Addition/Unordered 


Number of Tracks 
for Cylinder Overflow 


Extent Exit 
for DAM 


Continuation Lines 


Name of 
Label Exit 


Symbolic Number of Extents 


Device 


tb OL 


| Figure 3-34. File Descriptions for Two Printer Files on Model 10 Card System, Model 10 Disk System and Model 12 (5203 Printer) 
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ee 


Model 6: Figure 3-35 shows the File Description sheet 
entries for the dual tractors on the 2222 printer. The two 
printer files are assigned device names TRACTR1 and . 
TRACTR2 on the File Description sheet (columns 40-46). 


--TRACTR1 is the primary tractor (left-hand print unit) and 


TRACTR2 is the secondary tractor (right-hand print unit). 
Under Block Length (columns 20-23) for.each file enter the 
beginning print position for that file. Under Record Length 
(columns 24-27) enter the ending print position for that 
file. Print positions for TRACTR1 and TRACTR2 cannot 
overlap. 


| Output-Format Specifications 


Spacing and skipping on the two forms are completely in- 
dependent. You can specify different spacing and skipping 
for each output file. Spacing and skipping are entered in 
columns 17-22 of the Output-Format sheet. 


File Description Specification 


File Type Mode of Processing 


File Designation 
End of File 





Filename Sequence Type of File 
File Format Organization 


or Additional Area 


Record |- 
Length 


Length of Key Field or 
of Record Address Field 


Record Address Type 
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| Model 10 Card System, Model 10 Disk System and Model 12: 
Remember, there are 17 print positions you cannot use, — 
because there is a space between the left and right carriage 
tractors which cannot contain a form. This is important 
when you are planning where to position your printing on | 
each form. The first character to be printed on the form in 
the right carriage (PRINTR2) must be at /east 17 positions 
away from the last character on the form in the left carriage 
(PRINTER). Suppose you decide to use print positions 
1 through 80. Because the first character in the right car- 
riage must be at least 17 positions away from the last char- 
acter in the left carriage, print position 98 is the first avail- 
able position: 


80 (End position of the form in the left carriage) 
+17 (Number of print positions you cannot use) 


97 


Therefore, 98 is the first available position. If the length of 
your print line is 35 characters, the last position for the 
second form is 132. , 


Mico <I aeeeeeeiel File Addition/Unordered 
Nurnher of Tracks 
In this example, TRACTR1 has. 132 print vt 
positions; the form on the secondary 

tractor has 88 print positions. Ali 220 

print positions are used in this case, no- 

positions are lost between tractors. — 
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Figure 3-35. File Descriptions for Two Printer Files on Model 6 (2222 Printer) 
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-REYNOLDS INDUSTRIES, INC. 
111 W. SECOND ST. 
SAN JOSE, CALIF. 95113 ‘CUST. NO. 


~—430975 


TELEPHONE 
408-286-9100 


Se We KINGS 
498 RIVER STREET 
SAN JOSE, CALIF. 94067 


SOLD TO 


IMPERIAL DESIGN HOMES 
DIVISION OF Se We KINGS 
8343 BRANCH STREET 
SUNNYVALE, CALIF. 


ORDER DATE 
7/10/70 


SHIP TO 


95117 


SHIP DATE 
7/15/70 


ORDER NO. - 
‘13826 


SALESMAN 
Ge JONES 


ITEM EXTENDED 
QTY. NUMBER DESCRIPTION UNIT PRICE - AMOUNT 
96 


391468 
411116 
411132 
411732 


OCTAGON BOX 4 INCH 

TWINLITE SOCKET B 
_ SOCKET ADAPTER BRN 

SILET SWTCH IVORY 


511117 PULL CORD GOLD 


INVOICE REGISTER 
7/15/71 


INVOICE 
AMOUNT 


DISC. 
AMOUNT 


INVOICE CUST. 


EXTENDED 


NO. NO. AMOUNT 


13826 430975 $ 471.58 471.58 


13827 
13828 
13829 


431030 
432450 
434960 


FINAL TOTALS 


238.96 
57. 70 
208.62 


Figure 3-36. Sample Invoice and Invoice Register 
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234.18 
57.70 
204.45 
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| Example: End-of-the-Month Billing 


Assume that your company invoices its customers using 
your data processing system. It is your responsibility to 
prepare and print the invoices to be sent to the customers. 


-You are also going to keep an invoice register; a record of 


every invoice that is sent out. Since you have a dual feed 
printer, you will print both the invoice and the invoice 
register at the same time. You might name your two out- 
put files INVOICE and INVREG. 


The format of your output must-be determined. In this 
case, INVREG will have the standard length of 66 lines, 


while INVOICE will have a nonstandard form length of 50. 


Heading information is printed on the top of each report. 
INVOICE uses a preprinted form for much of its heading 
information. INVOICE has a 63 print position line and 
INVREG has a 50 print position line. Figure 3-36, insert 
A is a sample invoice and Figure 3-36, insert B is a sample 
invoice register. 


Since INVOICE has a nonstandard form length, it must be 
defined on the Line Counter sheet. You will use line 43 as 
the overflow tine. Figure 3-37 shows a sample Line Counter 
sheet. (Note that since INVREG has a standard form length; 
it does not have to be defined on the Line Counter sheet.) 


Line Counter Specifications 


Filename 


Form Type 
OL or Channel 


8 


Mare cl BL 


als 


Figure 3-37. Line Counter Specifications for INVOICE 
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You also want to have headings printed on the top of every 


: RPG §_ OUTPUT 
page. Because you do these operations only when an over- 


IBM International Business Machine Corporation 





flow indicator is on, you have to condition these operations _ Program i Punching | Graphic || 
by the overflow indicator. Figure 3-38 shows the File De- [Programmer fate mtetion 


scription sheets for Mode! 10 (Insert A) and Model 6 (Insert 
B). Figure 3-39 shows the Output-Format sheet to print 
headings at the top of every page. (Remember that skipping 
and spacing on the two carriages are independent.) 





Filename 


Note for Model 10 and Model 12 Users: Recall that the 
right form (in this case INVREG) must be at least 17 
positions away from the form in the left carriage. Because 
INVOICE will have a 63 print position line, you assign posi-. 
tions 1-63 to it. INVREG is a 50 print position line and you 
assign it to positions 81 through 130. 


Figure 3-39. Heading Specifications for INVOICE and INVREG | 


File Description Specification 


File Type 
Fite Designation 
End of File 
Filename 
: File Format 


Mode of Processing 
Length of Key Field or 
of Record Address Field 
Record Address Type 
Type of File 
Organization 
. or Additional Area 


Name of 
Label Exit 


Symbolic 
Device 


Extent Exit 
for DAM 


Core Index 


File Addition/Unordered 


Number of Tracks 
for Cylinder Overflow 


Number of Extents 


Record 





File Description Specification 
File Type Mode of Processing 


Length of Key Field or 
of Record Address Field 


File Designation Number of Tracks 


for Cylinder Overflow 
Record Address Type 
Type of File 
Organization 
or Additional Area 


Name of 


symolle Label Exit 


. Filename 
File Format 


Record 
Length 





Figure 3-38. File Description Sheet for End-of-Month Billing 
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Review 3 


Overflow and Fetch Overflow 


1. 


When you are not using overflow indicators or line counter specifications, but are 
allowing RPG II to handle overflow automatically, how many lines are assumed per 


page? What is the first line printed? What is the overflow line? 


Code the line counter ‘sabeincations which are necessary to define a form of 50 lines . 


with the overflow line 8 lines from the bottom. What entries must also be made on 
the File Description sheet? . 


When is the overflow indicator turned on and when is it tested? 

Describe a situation where printing can occur Siew the overflow line. 

How does the fetch overflow specification alter the normal program cycle? 
Given the following information’: supply the Fetch specifications, for the output 


shown in Figure 3-40, which will prevent printing records on or over the perforation. 


@ Number or printing lines per page is 66. The overflow line is 58. 

@ There are seven total lines in all. Since all are conditioned by the same control 
level indicator, they will all print when a level 1 control break occurs. 

© Overflow should be forced if the overflow line is printed prior to beginning total! 
output. 


@ Total lines 1, 2, and 3, must print on the same page. Total lines 4 through 7 — 
must print on the same page. 
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(@ Figure 3-40. Total Specifications (Question 6) 


Review 3. 3-33 


3-34 


Forms Alignment 
7: Why is accurate forms alignmentt important? 


8. What entries must be made in the RPG II specification sheets to repeat printing the | 
first heading line of a report until the forms have been correctly aligned? 


Editing 


9, Choose the correct edit codes for the following punctuation. 
1,342,650.00CR (for zero balance, print .00) 

. 1,246,900— (for zero balance, leave the field blank) 

. 1694824.25— (for zero balance, leave the field blank) 

. 12/13/71 


of 


Qaq4 


10. Construct an edit word for a 12-digit account number so that it will print out with 
the format XXX XXX XXX XX-X. 


11. On the Output-Format sheet, specify the edit code and any other entries necessary 
to print out a dollar amount with the format $**1,234.56CR. The field must end in 
position 50. If the tield is zero, print 00. 


NY 


) 


*PLACE 


12. What is the function of *PLACE? 


13. Inthe example shown, is *PLACE used correctly? If not, why not? 
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14. Write the output specifications to print two mailing labels in a row using *PLACE. 
The first label ends in print position 25, the second in 60. Each mailing label will 
have three lines and look like this: 

NAME (25 characters) 
ADDR1 (25) 
ADDR2 = (18) ZIPCODE (5) 

Dual Printer Output Files 


15. What does the use of the dual feed printer allow you to do? 


16. What limitations exist when designing forms for use with the Dual Feed Carriage 
Feature on the 5203 printer? 


17. How do you distinguish between the two feeds on the RPG II specification sheets? 
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Answers To Review 3 


1. Sixty-six lines are assumed per page. First line printed is O6 and the overflow line: 
is 60. 


ees '. File Description Specification. = 
File Type Mode of Processing : File Addition/Unordered 
File Designation Length of Key Field or . Extent Exit Number of Tracks 
4 eee - of Record Address Field é for DAM for Cylinder Overtlow 
Record Address Type ‘ Name of . ‘ Number of Extents 
Filename Sequence . / i Symbolie Label Exit j 
Core Index 
Key Field 


Type of File - . Device 
= 
Starting 


File Format Organization 
Location Option Entry 


or Additional Area 
0 41 42 43 44 45 47 48 49 50 51 52 54 5! 5 56 57 $8 59 60 61 62 63 64 6! 


Labels S/N/E/M 


Overflow Indicator 
Record 
Length 


Extension Code E/t 


1/0/U/C/D 
F/V/S/M/D 


10 11: 12:13 14)15/16 5 26 27 
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Filename 


Form Type 
FL or Channel 
OL or Channel 


61'62|63 64[65 66 67]68 
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Form length is 50 lines and overflow line is 42. Any overflow indicator OA-OG or 
OV must be entered in columns 33-34 of the File Description sheet. L must be 
entered in column 39 to indicate that Line Counter specifications are used. ° ~ 


3. If the printer has printed on the overflow line either during total or detail output, 
the overflow indicator specified in the File Description sheet is turned on. The over- 
flow indicator is tested and overflow output performed only after total output. 


4. a. When more than one detail or total line is printed during one cycle and a line 
other than the last total line is printed on the overflow line. 
b. When the last detail line for a control group prints on the overflow line, the total 
lines for that group will print below the overflow line. 


5. The overflow indicator is tested prior to printing each line specified with fetch over- 

flow rather than waiting until all total output has occurred. If the indicator is on 

a when tested, overflow output is performed immediately and then the line specified 
is printed. 


- 3-36 


6. =F incolumn 16 of lines 1 and 7 of Figure 3-40. F in column 16 of line 1 causes 
forms to advance if the overflow indicator is on, assuring that total 1 will not print 
) below the overflow line and total 3 will not fall over the perforation. Since totals 4 
through 7 must all print on the same page and will not all fit below the overflow line, 
enter F in the specifications for total 4 to cause a skip to the next page if the over- 
flow indicator is on. Since totals 5-7 must print on the same page as total 4, no fetch 
specification should be entered for them. 


7. Forms must be aligned accurately so that printing is correctly positioned on each 
page and so that printing occurs exactly where you want it, not above or below. 


8. ‘There must be at least one line on the output sheets conditioned by the 1P indicator. 
A ‘1’ must be entered in column 41 of the control card. 


ao oOo » 
<ESAxAD 


— 10. ~ Blank spaces show where digits are to be placed and &’s show where blanks go. The 
entire word must be enclosed in quotes. 
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11. The A edit code will zero suppress and insert commas, decimal! points, and the:credit 
sign CR. The asterisk entered in columns 45-47 will cause all places zero suppressed to 
be filled with asterisks. The dollar sign must be specified on the line following the 
edit code. When printed in position 38, it will come right before the asterisks. 





; RPG OUTPUT SPECIFICATIONS Suen. D> Sarpy Moe 
IBM International Business Machine Corporation 


1 2 75 76 77 78 79 80 

1 é 

rev ea re 

ror foe dn Pe PO LL oti 
" t v 


Pit Output Indicators 
Field Name |f 
*AUTO $ 
20421 22 132 33 rT TT 


mI mae 
HH tte MOUNT 
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5 69 70 





eee 


12. The function of *PLACE is to easily code the printing of duplicate information on 
the same output line. *PLACE places information from print position 1, through 
the highest end position previously defined for a field into the print positions indi- 
cated by the end position in the *PLACE entry. 


13. [tis not correct. The end positon in the *PLACE specification is not high enough. 
The duplicated information will overlay the field called ACCTNO. The end position 
on the *PLACE line should be at least twice the nlgnest end position previously | 
specified for that record. . 


14. Two labels alet be srinted. Therefore, for each line you must specify the original 
field and a *PLACE entry, which will cause the contents of the yee field to be 
duplicated. —S 


L 
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The dual feed carriage allows the printing of two independent reports simultaneously. 


15. 


16. 


A minimum of seventeen print positions must be left blank between the two output 


~ forms. 


Model 10 Card System, Model 10 Disk System, and Model 12: The only difference 


oot) Age 


is that the device name on the File Description sheet for the left carriage is PRINTER 


_and for the right carriage is PRINTR2. 


Model 6: The only difference is that the device name on the File Description sheet 


for the left tractor is TRACTR1 and for the right tractor is TRACTR2. 
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Chapter 4. Card Output Operations 


- CHAPTER 4 DESCRIBES: 
Puncned output. 
Printing on cards. 
Using one file for both input and output. 
Selecting the saeket for output cards. 


Merging input and output file cards. 


BEFORE READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
Using the printer to produce a simple listing. 
Using control fields. 


RPG II object program cycle for detail and total operations. 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 


Se 


Coding for punching a combined or output card file; summary punching. 
Formatted printing and unformatted printing (*PRINT) on cards. 
Uses and coding for combined files. 
‘Stacker selecting input, combined, and output card files. 
Coding for merging input and output card files. 
Note: You can use the review questions contained in Review 4 at the end of this 
chapter to test your comprehension of each topic in the chapter. Questions are 


grouped according to the topic to which they apply. Answers follow the review 
questions. 


Card Output Operations 4-1 


INTRODUCTION 


Thus far, in this manual, the program output usually has 
been a printed form or report. Punched cards generally 
have been used as a source of input data. However, cards 
can be used for output as well as input. This chapter des- 
cribes RPG I| coding for output operations using the IBM 
5424 MFCU, available on the System/3 Models 10 and 15, 
and the {BM 2560 MFCM, available on the System/3 Model 
15 only. 


You might want to have card output for many reasons. 
Perhaps you want to generate a new file or change an input 
file in some way, such as by reformatting the records, add- 
ing data, deleting data, adding new records, or deleting un- 
wanted records. The output you choose might be data 
punched on the cards, printed on the cards, or both. In- 
formation can be printed on cards for identification, inter- 
pretation of the punched data, or any other purpose you 
desire. You can punch and print data on blank cards or on 
cards that already contain data. You can also direct cards 
to a specific stacker or more output file cards with cards 
from an input file. 


PUNCHING AND PRINTING ON CARDS 


Punching and printing on individual output cards are con- 
trolled separately. Punched cards need not be printed; - 
printed cards need not be punched. 


Punched Output 
Punched output can be used to: 


@ Create a file of cards that is different from the input card 
file 


_@ Add new records to a card file 
@ Add fields to input records 
-@ Punch a summary card from a group of input cards 


RPG I coding for punched output is similar to coding for 
printer output. Either the primary hopper (device name 
MFCU1 or MFCM1) or the secondary hopper (device name 
MFCU2 or MFCM2) can be used as the output device; the 
other hopper is used as the input device. In some cases, 
punching can be done on the input cards themselves (see 
Using One File for Both Input and Output, in this chapter). 
Remember, however, if only one MFCU hopper is used, it 

| must be MFCU1 (Model 10 Card System only). 


On the Output-Format sheet, you can specify heading, de- 
tail, and total output, just as you can with a printer file. In - 
some cases, you may want to punch only total records by 
summing the data on several input records and punching a 
separate card for the total. This is known as summary © 
punching. Do not specify an edit code for punched output 
unless you want to have punctuation punched into the out- 
put cards. 


Printing On Cards 


It is advantageous to print the same information on the 
card as was punched on the card. This way you can easily 
interpret what information is recorded on the card. Also, 
printing information on the card makes it easier to recreate 
a card that is damaged to the extent that it cannot be read 
by the MFCU or MFCM, or duplicated by the data recorder. 


Although you. may print the same information on the card 


- that is punched on the card, it is not always'necessary to 


do so. You may print entirely different fields from those 
that are punched. 


The 96-column card has space at the top for four lines of 
printing (Figure 4-1). Each line can contain 32 printed. 
characters, for a total of 128 print positions. 


|. The 80-column card can be printed only on the MFCM 


Model A1 with the optional print feature. Up to six print 
lines can be used. Each line can contain up to 64 printed 
characters, for a total of 384 print positions. 


The MFCM print heads can be set to print in 25 different 
print line positions, from above the 12-punch position to 
below the 9-punch positions (Figure 4-2). The print heads, 
numbered 1 through 6, must remain in sequence from top 
to bottom, with print head 1 at the top. Therefore, with 


_six print heads installed, print head 1 cannot be set below _ 


line 20 and print head 6 cannot be set above line 6. Inter- 
mediate line positions are located on and between each row 
of punch positions. Print-position 5 (between the 11-row 


and 0-row) should be avoided, if possible, because the feed 


wheel may cause some smudging of characters printed in 
that position. In punched fields, printing in even-numbered 
line positions should be avoided because punching may 
obliterate some characters. 


Formatted Printing (MFCU) 


:) Using formatted printing, you may print a field or constant 

in any of the 128 print positions available on a 96-column 
card. The first three lines are the lines usually printed. The 
fourth is printed only if necessary because printing on the 
fourth line increases considerably the amount of time needed 
to print, and thus increases the time needed to do the job. 


Printing lines 


12.3 4 5 6 7 B 9 1 MN 12 13 14 15 16 17 16 19 20 21 22 23 24 25 26 27 28 29 30 31 32 
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Figure 4-1. Printing Lines ona 96-Column Punch Card 
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@ Figure 4-2. Printing Lines on an 80-Column Punch Card 
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For each field or constant you wish printed by the MFCU, 
you must make the following specifications on the 
Output-Format sheet: 


1. If a field is to be printed, enter the field name in col- 
umns 32-37. | 


2. Enter * in column 40 to indicate that the field is to 
be printed not punched. 


3. Enter any end position from 001 to 128 in columns 
41-43. . 


4. If a constant is to be printed, enter the constant in 
columns 45-70. 


For example, to print the fields on the card shown in Fig- 
ure 4-3, the specifications in Figure 4-4 tines 06-10 are 
necessary. You indicate punching of these fields by speci- 
fying an end position without the asterisk (see Figure 4-4, 
lines 02-05). If yourintend to punch fields and print fields 
you need two specifications per field. If you have seven 
fields fo be both punched and printed, you need 14 specifi- 
cations. 


‘ 


Because printing and punching are two separate functions, 
it is possible to print a field without punching it and punch 
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Figure 4-3. Formatted Printing on.a 96-Column Card 


a field without printing it. If you punch and print the same 
field, you may put each in different positions. In other 
words, you may format the punched fields in a different 
way than you format the printed fields. 


SPECIFICATIONS , : Coie 050° 


Printed 


75 76 77 78 79 80 I 


Plus Sign 
Y = Date 
Field Edit 


a 
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Figure 4-4. Specifications for Punching and Printing on a Card (Formatted Printing — MFCU) 
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Formatted Printing — MFCM 


Using formatted printing, you can print a field or constant 


on any six of the 25 print lines available on an 80-column 
card. For each field or constant you wish printed by the . 
MFCM, you must make the following apecitications on the 
Output-Format sheet: 


1. When printing a field, enter the field 1 name in columns 
32-37. 


2. Specify a print head number (1-6) in column 41, 
3. Specify a print end-position (01 -64) in columns 42 
' and 43. (The leading zero is required when specifying 


print positions 01-09.) 


4, When printing a constant, enter the constant in 
columns 45-70. 


For example, to print the fields shown in Figure 4-5, the 
specifications shown in Figure 4-6 are necessary. Coding’ 
lines 02 through 05 cause the fields to be punched. Coding 
lines O6 through 10 cause the fields and a constant, 
BALANCE, to be printed. As you can see, two specifications 
are required for each field that is to be both punched and | 
printed. In order to obtain the desired printing results, the 
MFCM print heads must be aligned mechanically prior to 
running the piearert: 


Note: The fourth line of printing also could have been 
printed using print head 4, with print heads 5 and 6 set to 
line positions lower on the card. 


Bc’ -antln) and punching are two separate functions, 
it is possible to print a field without punching it and to 
punch a field without printing it. 
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@ Figure 4-5.: Formatted Printing onan 80-Column Card 
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SPECIFICATIONS 
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Printed in U.S.A. 
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1 2 : . 
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ae eee ee 
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Date 

Field Edit 
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End 
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Constant or Edit Word 
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ee 
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SS itp 8 BS 


@ Figure 4-6. Specifications for Punching and Printing ona Card (Formatted Printing — MFCM) 


Unformatted Printing (*PRINT) — MFCU and MFCM 


Using formatted printing, recall that if you wish to both 
punch and print a field, you must have two entries per field 
on the Output-Format sheet: a punch entry and a print 
entry. If you want several fields to be both punched and 
printed, there is a great deal of coding involved. 


RPG II has a special reserved word, *PRINT, which allows 


you to punch.and print fields and constants with less coding. | 


When *PRINT is specified, it causes all previous fields 
described for the record to be printed. Use of *PRINT is 
known as unformatted printing. 


Figure 4-7 shows the use of the *PRINT specification. 
NAME, ADDR, ACCTNO, and BAL are to be punched. 
Following these field names in columns 32-37 is the entry 
*PRINT. This entry causes the previous four fields to also 
be printed on the card (see Figures 4-8 and 4-9). 


46 


Using *PRINT with the MFCU causes fields and constants 


- to be printed in positions corresponding to the punch posi- 


tions. For example, ACCTNO is punched in positions 41-48 
and also is printed in positions 41-48. _ 


On the MFCM, there is not space to print 80 characters on 
one line. Therefore, data punched in columns 1-64 is 
printed in print positions 1-64 by print head 1; data punched 
in columns 65-80 is printed in positions 49-64 by print 
head 2 (Figure 4-9). 


The word *PRINT can be used only once for a record and 
must be entered after the description of all fields that are 
to be both punched and printed. Suppose, instead of print- 
ing all four fields (NAME, ADDR, ACCTNO, and BAL), 
you want to print only NAME and ACCTNO. In this case, 
the entry *PRINT must follow NAME and ACCTNO. 
ADDR and BAL must be described after the *PRINT entry 
(Figure 4-10). 


Columns 7-22 and 39-74 must always be left blank on the 
*PRINT specification line. 
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Figure 4-8. Unformatted Printing on a 96-Column Card 


Figure 4-7. Punching and Printing on a Card Using *PRINT 


(Unformatted Printing) 
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Figure 4-9. Unformatted Printing on an 80-Column Card 
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Figure 4-10. Using *PRINT to Specify Fields When Some are 
Punched Only 


You may use any indicator in columns 23-31 to condition 
_ the *PRINT entry. That specification will then be per- 
formed only when the condition set by the indicator is 
met. For example, according to the specification in Fig- 
ure 4-11, line 05, the fields will be printed only when 10 
and 21 are both on at the same time. 


Editing A Field Printed on the Card 


Any field that is to be printed, using either formatted or 
unformatted printing, can be edited. This, of course, will 
make the printed field easier to read and understand. 


Editing a field to be printed on the card is done in the same 
way as editing a field to be printed on the printer. How- 
ever, editing should be kept at a minimum so that the length 
of the printed field won’t be considerably larger than the 
length of the punched field. Zero suppression or merely re- 
“moval of the sign are often done since they do make the 
printing easier to read, but still keep the printing in a one- 
to-one relationship with the punches. 
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Figure 4-11. Conditioning *PRINT Entry 


USING ONE FILE FOR BOTH INPUT AND OUTPUT 


In your experience with RPG II, you have used card files as 
input files and output files. Suppose, however, you wanted 
to punch into the same card that was read into the com- 
puter. Is it possible to use input and output files to do this? 
No, input cards are only read and output cards are only 
punched or printed. What you need is a combination of the 
two. The RPG II language allows such a file combination. 
This type of file is called a combined file. 


Note: \n this discussion, only the MFCU is used for refer- 
ence; unless noted otherwise, the MFCM can 1 be used in the 
same way. 


_ Punching Into the Same Card that is Read 


A company keeps a daily record of the amount of each item 
sold. At the end of the week the daily amount sold for each 
item is punched into the card in six different fields, one field 
per day. These cards are then used in a program which totals . 
the daily amount sold for each item and punches that total 

into the same card that contained the daily amounts. | 


Figure 4-12 shows the format of the data card which is read. 
Each card contains the end of the week date (DATE), the 


- item number (ITEMNO) and daily amounts sold (FLD1 


through FLD6). Figure 4-13 shows the same card after it 
has been punched. TOTAL is the field punched after the 
total amount sold has been calculated. 
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Figure 4-12, Combined File Card Read 
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Figure 4-13. Combined File Card After Punching 
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To describe this program, you will need four types of 3 On the Input sheet (Figure 4-14, insert B) you should de- 


specifications sheets: File Description, Input, Calculation, fine only the fields which are to be read. Remember the 
and Output-Format. On the File Description sheet, you TOTAL field is not in the cards when the cards are read 
define the file as a combined file with a letter C in column 15. — and therefore, is not described on the Input sheet. Since 
File Description entires for a combined file are the same as the TOTAL field is to be created during the job, it is de- 
those for an input file except for column 15. (See Figure fined on the Calculation sheet (Figure 4-14, insert C). « 

| 4-14, insert A.) Cards will be both read and punched on | | 
MFCU1. With the exception of the device name, specifica- The Output-Format sheet (Figure 4-14, insert D) describes 


tions in Figure 4-11 apply to the MFCM, as well. only the information that is to be punched into the card. 
= Paps Here again you describe the TOTAL field. 


Note: Be sure the card columns to be punched contain 
blanks, to prevent problems with invalid punch combinations. 


' 
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Figure 4-14 (Part 1 of 2). Specifications for Reading and Punching Each Card 
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Figure 4-14 (Part 2 of 2). Specifications for Reading and Punching Each Card 


Punching into a Blank Card in the File 4% 1... Onhand, which contains the number in stock at the - 
beginning of the month. 
Vou have just learned how to use a combined file when you 


wish to read and punch the same card. What if you wish to 2: Issues, which contains the number sold during the 
read several cards and then punch another card in the same — month. There is one of these cards for each week. 
file?: Remember any time you want to read and punch cards 

from the same file, that file must be defined as a combined | 3. Receipts, which contains the number added to stock ' 
file. | through reorder. 

Assume that a company which keeps a weekly record of 4. New Onhand, which is blank, . After calculations have 
items sold, uses these records at the end of the month to been performed to determine the number on hand, 
determine the quantity of items on hand. For each item, this number and the date anda code are punched into 


four different types of cards are read (Figure 4-15). the card. This card, when punched, will be used as 
next month’s Onhand card, and will be in the same 
format as the current Onhand card. 


sv 


Card Output Operations 411 


Each of these card types is identified by a code in column 
96 (see Figure 4-15). (This code would be column 80 if - 
the MFCM were used.) 
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Onhand Card = Receipt Card 
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Figure 4-15. Four Card Types 


4-12 


Again, you will need four types of specification sheets to 
write your program: File Description, Input, Calculation, 
and Output-Format. On the File Description sheet, you 
must enter the filename, file type, and device (see Figure 
4-16, insert A). Since this file is both read and punched, 
the file type must be C to denote a combined file. 


On the Input sheet, you must describe all four card types 

and assign record identifying indicators. These indicators 

will be used later to condition those operations which are 
to occur only when a specific card type has been read. 


These cards must be read in a certain order. The onhand © 
card must come first, the new onhand (blank). card must» 

~ come last. The issues and receipts cards may be in either 
order, but must always be in the same order for any pro- 
gram. For this program, assume that receipts cards follow 
issues. Remember to indicate that cards are to be in a cer- 
tain sequence by using numeric sequence entries for all card 
types. These entries will direct the program to check for 
sequence. Figure 4-16, insert B, shows input specifications 
for this program. 


On the Calculation sheet, you define the calculations 
(Figure 4-16, insert C) which must be performed to deter- 
mine amount on hand. The record identifying indicators - 
assigned on the Input sheet are used to condition calcula- 
tions. For example, only when an issues card is read (02 is 
on) will number sold (ISSUES) be subtracted from INSTOK. | 
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Figure 4-16 (Part 2 of 2). esenicnGans: for Reading and ee Combined File Cards 


On the Output-Format sheet (Figure 4-16, insert D) you 
must show the fields which are to be punched. Since only 
the blank card is punched, punching occurs only when 04 

is on. Because the card punched will be used as next month’s 
Onhand card, ITEMNO, DATE, INSTOCK and a code must 
be punched. . 


When To Specify a Combined File 


How do you know whether to describe a card file that must 
be read into the computer as an input or as a combined file? 
If you remember these basic rules you will have no trouble 
deciding. 


1. If the file contains cards that are to be both read and 
punched, it must be a combined file. 


2. lf cards in the file are to be stacker selected on some 
basis other than card type, the file must be described 
as a combined file (see Stacker Selection, Selecting on 
a Basis Other Than Card Type). 
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STACKER SELECTION 


Stacker selection is the means by which you can separate 
certain cards from all others in the file. If stacker selection 
entries are not made, all cards automatically fall into speci- 
fic, predefined stackers: 

MFCU1: Stacker 1 

MFCU2: Stacker 4 

MFCM1: Stacker 1 

MFCM2: Stacker 4 (Model A2) or Stacker 5 (Model 

A1) 


Note: Unless stated otherwise, this discussion applies to 
both the MFCU and the MFCM. 
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Input and Combined File Cards 


Input file cards are stacker selected by input specifications. 
Combined file cards can be stacker selected by either input 
or output specifications. 


Selecting on the Basis of Card Type 


Stacker selection by input specifications must be on the 
basis of card type. This means you may separate all cards 
of one type from the input file by specifying a special 
stacker into which they should be stacked. 


Suppose you want to create a monthly list of all items ina 
retail store. Three card types are used: one for new items, 
one for discontinued items, and one for all other items. 

The manager wants to take all cards describing discontinued 
items out of his file. He can do this by specifying the stacker 
into which the card type is to be selected. The specification 
in Figure 4-17, insert A, line 02, will separate the discontin- 
ued item cards (card identified with a D in the last column) 
from the other cards by putting them in stacker 2. 


Notice that the OR relationship was used in describing the 
three card types. When stacker selection is done with the 
OR relationship one rule must be kept.in mind: each card 
type will fall into the stacker indicated for it. For example, 
Figure 4-17, insert A, shows the stacker selection entry 2 
for the second card type. The other card types have no 
stacker selecton entry. They are, therefore, stacked in 
stacker 1 if they were entered in the primary hopper or in 
stacker 4 or 5 if entered in the secondary hopper. According 
to Figure 4-17, insert B, card type 02 falls into stacker 2, 
card type 03 falls into stacker 3. Where does card type 01 
fall? It will fall into either stacker 1, 4, or 5 depending 
upon the device used and the hopper in which the file was 
entered. ; 


Selecting on a Basis Other Than Card Type 


Suppose you wish to stacker select input file cards on some 
basis other than card type, such as the result of calculations, 
the results of matching records, or the contents of an input 
field. For example, assume that the cards which contain 
information concerning new, discontinued, and available 
items in the store also contain the amount on hand at the 
end of the month. In addition to listing all items, records 
of items which need to be reordered are selected to a 
separate stacker. The critical reorder point occurs when 
there are 25 items or less left on hand. (This, of course, 
does not apply to discontinued items.) Thus, in the cal- 
culations, ONHAND is always compared to 25. If the 
amount is equal or less than 25, the item needs to be re- 
ordered. All cards describing items to be reordered are to 
be separated from the others in the file by stacking them 

in a special stacker. 


Where would you specify the stacker select entry that 
would do this? There are only two possibilities — Input - 
sheet or Output-Format sheet. Remember that input cards 


’ can be stacker selected on the Input sheet on the basis of 


card type only. In our example, not all cards of any one 
type will describe items that need to be reordered. There- 
fore, the selection is not on the basis of card type and can- 
not be specified for an input card on the Input sheet. This 
leaves only the Output-Format sheet on which to specify 
this stacker selection. But since our file is not an output 
file, how could it be specified on the Output-Format sheet? 
Remember that a combined file serves for-both input and 
output. Therefore, a file from which cards are to be: 
stacker selected must be defined as a combined file. 
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| Figure 4-17. Stacker Selecting Cards in an OR Relationship 
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compared with 25. 


Figure 4-18 shows the entries which are necessary to stacker 


select all cards (except discontinued) cards) which contain 
25 or less in the ONHAND field. The file would be de- 
scribed as a combined file by placing a C in column 15 of 
the File SFPD sheet. 


Figure 4-18, insert A, shows that the ONHAND field is 

If the compare is equal or less, in- 
dicator 10 turns on to indicate that the item should be 
ordered. Indicator 10 is then used on the Output-Format — 
sheet to condition the stacker selection entry (Figure 4-18, 
insert B, line 01). When 10 is on (there are 25 or less of 
the item left) and the card is not a discontinued item (in- 
dicator 02 is not on), the card is selected into stacker 2. 
All other cards go into stacker 1. 


Rules for Stacker Selecting Cards from a Combined File . 


Combined file cards can be stacker selected by both input 
and output-format specifications. Input stacker selection 
is based on card type alone; output stacker selection can 
be on any other basis. In fact, you can stacker select some 


RPG CALCULATION SPECIFICATIONS 


IBM International Business Machine Corporation 


card types by input specifications and others by output- 
format specifications. However, one card type should not 
have both types of stacker selection specifications. If it 
does, the input entry is ignored. Furthermore, if you are 
punching or printing on combined file cards that are also 
to be stacker selected, the stacker selection entry must be 
on the Output-Format sheet. 


Stacker Selecting Output File Cards 


Output file cards are stacker selected by output specifica- 
tions. For example, stacker selection by output specifica- 
tions can be made on the basis of results of calculations, 
matching records, content of fields, and error conditions. 
Output stacker selection can be based on card type, but 
card type selection is usually done with input specifications. 


Consider an end-of-the-month inventory program that: (1) 
finds the balance on hand for each item, (2) determines if 
and when an item should be reordered; and (3) finds any 
items that are overstocked. 
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Figure 4-18. Stacker Selection on the Basis of Calculations 
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Two files are used: an input file and an output file. The 
input file contains three types of cards (Figure 4-19): 


1. Inventory Balance cards, which contain the number 
in stock at the beginning of the month, and the max- 
imum and minimum quantities which should be kept 
in stock, 


2. Issue summary cards, which contain the total number 
issued during each week. Since this is an end of the 
month job, there may be several of these. 


3. Receipt cards, which contain the number added to 
stock through reorder. 


Each item must have a balance card. The other two cards 
are optional. The output file contains blank cards. 


For each item, the total number in stock will be calculated 
from information on the input cards and then punched into 
a blank output file card along with all other fields found on 
the balance card. The format of the output card must be 
the same as the input balance card, since this output card 

is used as the balance card for next month’s inventory. 


Before the balance on hand is punched into the blank cards, 
the amount is compared to the maximum and minimum | 
quantities in stock established for each item to determine 
reorder procedure. Asa result of the comparison, four con- 
ditions could occur: 


1. If the amount in stock is zero or back-ordered, the | 
item should be reordered immediately. 


2. If the amount is greater than zero but equal to or 
below the minimum, normal reordering procedures 
should be followed. 


3. If the amount is between maximum and minimum, 
| the item does not need to be reordered. 


4. If the quantity is greater than the maximum, the 
manager should be notified of the overstocked item. 


Instead of putting all newly punched balance cards into 
one stacker, it would be more convenient, when preparing 
to reorder, if they were stacked into different stackers: 
one stacker for items requiring immediate attention (re- 
order immediately or greatly overstocked), one for items 
to be reordered normally, and one for items which need 
not be reordered. To separate them, you specify different 
stackers they could go into on the basis of the amount in 
the INSTOK field. 
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Receipt Card 


Figure 4-19. Cards Used for Inventory Job 
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From which file do cards come that are to be stacker 
selected? They come from the output file since they are 
the.newly created balance cards. Therefore stacker selec- 
tion entries must be made on the Output-Format sheet. 
Stacker selection entries are on the basis of the compare 
operation. Thus these compare operations must set indi- 
cators which will be used on the Output-Format sheet to 
indicate into which stacker cards must fall. Figure 4-20 
shows the program specifications. 


Figure 4-20, insert A, lines 01, 02, shows operations used 
for finding the number in stock. When a control break 
occurs (a card for a new item is read) the number in stock 
is compared as many as three times (lines 04-06) to deter- 
mine into which stacker. the cards should fall for reordering 
purposes. Resulting indicators are set off (line 03), since 
improper selection could otherwise occur due to multiple 
indicators set for a single condition. 


INSTOK is first compared to zero. If it is equal or below, 
indicator 10 is turned on. If INSTOK is greater than zero, 
it is compared to the minimum quantity. When INSTOK 
is equal to or less than minimum, indicator 20 is turned.on. 
If INSTOK is greater than minimum, it is then compared 
to maximum. Indicator 10 is turned on if INSTOK is 
greater than maximum; indicator 30 is turned on if it is 
equal or less. 


Any of these indicators can be set: 10, 20, 30. Since they 
indicate the amount in the field INSTOK, they also indicate 
into which stacker cards should fall. (See Figure 4-20, in-. 
sert B.) If 10 is on (INSTOK is zero or less or greater than 
maximum) cards go into stacker 4, If 20 is on (INSTOK is 
greater than zero, but equal to or less than the minimum), 
cards go into stacker 2, If 30 is on (INSTOK is greater — 
than MIN but less than or equal to MAX) cards go into © 
stacker 3. In all cases, five fields and a constant are punched 
punched on each blank card before it is stacked. 


Rules for Stacker Selecting Cards From An Output File 


If no stacker selection entry is made for the output file, 
cards automatically fall into predefined stackers — stacker 1 
if the file is in the primary hopper; stacker 4 if the file is in 
the secondary hopper. You may; however, cause cards to 

be stacked in any of the four (or five) available stackers 
merely by entering 1, 2, 3, 4 or 5 (5 for MFCM Model At in 
column 16 of the Output-Format sheet. 


All cards from the same file will fall into the specified 
stacker unless indicators are used in columns 23-31. If, 

as in this example, you want cards to fall into different 
stackers, you must use indicators set by calculation opera- 


'\ tions to condition the stacker selection specifications. 


ug 


Merging Input and Output File Cards 


Putting cards from two different files into the same stacker 
is known as merging cards. Any two files can be merged. 
To do so, you merely specify the same stacker for each file. 


When input and output file cards are merged, the output 
file card for each program cycle is stacked in front of the 
input file card read at the beginning of the cycle. Why are 


~ output cards stacked before input file cards? According to 


the way the MFCU and MFCM operate: 


1. An input card is not stacked until the next input card 
is read. 


2. Any output card that is punched is stacked immedi- 
ately. 


These statements are the key to the order of merging. Con- 
sider what this means during a regular program cycle. When 
an output file card is punched, it is stacked, This could be 
either at total time or detail time. However, ‘the input card: 
read at the beginning of the cycle is not stacked until the 


‘next card is read. This results in the output card being 


stacked in front of the input card. Most often, however, 
you would want the merged cards ordered so that Inpur 
cards precede output cards. , 


Reversal of the normal stacking order can be accomplished 


‘by specifying look ahead fields or dual input areas for the 


input file. When either of these is specified, input cards are 
stacked before output cards. 


Stacker selection cannot be specified for input files with 
dual input areas. Therefore, if you wish to merge cards 
from the input and output file, you must merge the cards 
into the default stacker for the input file (defined pre- 
viously — see Stacker Selection). 
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| Figure 4-20. End-of-Month Inventory Job 
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Review 4 


Punching and Printing on Cards 


1. 


2. 


4. 


5. 


Why is it important to print on a card the same information punched in a card? 


Using the following information, write the output-format specifications to punch 
and print the following fields on output cards: 


Field _End Position 

CUSTNO 5 

NAME 26 

AMT 32 

INVNO 38 

DATE ~ 44 

2 (constant) 96 (use 64 for MFCM) 


The information should be printed in the same relative positions as it was punched. 
Do not use *PRINT for this. For the MFCM (Model 15 only), use print head 1 for 
all fields. 


Do problem 2 using *PRINT. 


| Using One File For Both Input and Output 


When should a file be specified as combined? 


If all master cards in a file are to be separated from item cards in the same file, the 
file type should be specified as 





True or False? Both printer files and card files can be combined files. 
An electric company wishes to find the amount each customer owes for the electricity 
he used during the past month. The input file consists of three types of records for 
each customer: 
@ READ1 which contains the meter reading at the beginning of the month. 
@ READ2 which contains the meter reading at the end of the month. This card 

will be used as next month’s READ1 card. It now contains a blank in the last 


column, and must therefore be punched with a 1 in the last column. 


e AMOUNT DUE which contains a blank field (AMTDUE) which will be punched 
with the amount each customer owes. 


For each account these three cards must be present and in the order indicated. 
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Amount Due Card 


The program must: 


© Find the number of kilowatt hours (KWH) of clectricty used Curing the month. The 
reading has two age places. 


® Multiply the number of kilowatt hours used by rate per kilowatt hour to find amount 
due. (AMTDUE has 2 decimal places.) : Rate is $.05 per KWH for the first 50 KWH, 
then $.02 per KWH for all over the first 50 KWH. 

@ Punch the amount due on the appropriate card. 


® Separate all three card types into different stackers. 


Make the necessary entries on the File Description, Input, Calculation, and Output-Format 
sheets. 
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Matt 


Stacker Selection 


8. If stacker selection is specified on the Output-Format sheet during detail output 
for card 3, which card will be selected? Which card will be selected if stacker selec- 
tion is specified during total time output after control group A? 





9. At each stop they make, drivers working for a fuel oil company record beginning 
and ending meter readings and the number of gallons of oil delivered to the customer. 
Later the account number, meter readings, and gallons delivered are punched into 
cards. 


All regular customers are charged 15¢ per gallon. However hospital and government 
agencies receive a 2% discount. The code to show which customers receive a dis- 
count is in the account field. If the last digit is 0, no discount is given; but if the 
last digit is 5, the discount is given. 


Write the calculation and output-format specifications to: 

a. Check the driver’s calculations in determining gallons delivered to each account 
by subtracting beginning meter reading from ending meter reading. 

b. Calculate the amount charged to each account (AMOUNT). 

c. Find total number of gallons sold for the day (TOTALG) and total amount 
charged (TOTALA). 

d. Print a report listing daily transactions and totals. If there is an error in driver’s 
calculations, print the account number, code, and a message, ‘CALCULATION 
ERROR’. 

e. Stacker select cards for customers receiving discounts into stacker 2. All others 
go into stacker 3. 
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The input specifications and the layout of the printed report are as follows: 
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Answers to Review 4 


1. Printing the same information that is punched on a card: 
a. Enables you to easily see what is on the card. You don’t have to analyze each 
punch combination. 
b. Makes it easier to recreate a card that is damaged to the extent that it cannot be 
processed. 
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For MFCM, change 96 to 80. 
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4, A file should be specified as combined if it is both read and punched or if cards 
from the file are stacker selected on a basis other than card type. 


5, Input (stacker selection is on basis of record type here.) 


6. False, only card files can be designated as combined files. 
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Since cards in this file are to be both read and punched the file must be defined as 

a combined file (C in column 15 of the File Description sheet). The card type 

identified by a 1 requires no punching, and therefore can be stacker selected on the 

Input sheet. A 1 was entered in column 42 of the Input sheet to indicate the stacker. 

Leaving this column blank would also indicate that the card type goes into stacker 1 

because cards entered in primary hopper of the MFCU are automatically stacked in 


stacker 1. Output operations are performed on card types 02 and 03. Stacker selec- 
tion is, therefore, specified for each on the Output Specifications Sheet in column 16. 








3 oO 
Po fe fof After 
8 
nN 
a 
————] , 
2 
ee 
| ]8 
| |g 
| |g 
= 
w 
Nn 
wo 
w 
> 
| [| je @ 
poo Se a 
a oO 
wo 
Qa 
a 
> 
o 
a 
= 
> 
NO 
> 
&é 
= 
z 
& 
| 
[4a 
. 
3 
f 
eo 
. 
| {és 
| |3 
| |3 
uo 
a 
nD 
n 
a 
g 
B 
a 
a 
ou 
4 
o 
& 
a 
oO 
a 
co 
= 
a 
NO 
cous 
wo 
a 
g 
a 
a 
a 
a 
~s 
n 
a 
a 
oOo 
x 
a 
NN 
a 
a 
| fa 
~ 
> 


[| wp feo Stacker # /Fetch(F) 
a a 











8. a. Card 3 — the card that is being processed. 
b. Card 3 — the card which caused the control break. 





RPG CALCULATION SPECIFICATIONS Form Gx21-9059 
IBM International Business Machine Corporation : 


a : “ 75 76 77 78 79 80 
Programmer Date Instruction | Punch —_| ____ Identification 


Resulting 
Indicators 
[| Arithmetic | 
: Min: 
21z | Plus [Minus] Zero Carriere 
















Factor 1 Operation Factor 2 


2j1< 


CI- 
6 |V 


N 
= 
, rs 


~ 









x 

S 

5 
a 

oy 

° 

~ 

2 

5 
2 

fa 


a 
a 
a) 
gs 
a 
@ 5 

c 
8 a 
a 






elder el 


PTT kldee PTET LLL. 
a A bee 


a outa 
mabe 





SQN | 


) 






Poh se le | 
a 








= 
Se fz 
: 
: 
eel le 








KCTS Set 
Saisie 
ores ss 


4-28 


RPG OUTPUT _ SPECIFICATIONS Gx21-9000 yl oso" 
IBM International Business Machine Corporation 


12 75 76 77 78 79 80 
= moons Pomme | TT TT [Tyee] 
En Cc LL st 


aerate 
‘ CR emove 

‘Yes Y = Date 
Field Edit 


Filename End No Yes Zero 
: Positon No No Suppress 


P/B/L/R 


[= {> 














3 


po fo fate ts |=elefelsTolal=Te] 
| OO} | | | OR] is ber oP 


P| rt ft tT | eet 


es 
PRA TT oe ea 
Pa TS als oe I Ss ae Vd de 


> 
Ht} Bt tt s 
fe 
ao 


m= 
re eee Tole te ee | 
a fo 
pe hesta rs ee Mie Se Aa es Ss Sed le | 





You must be certain to check ta see if the code is 5 or 0. The resulting indicator showing the 
result of the compare is then used on the Output-Format sheet to show into which stacker 
cards should fall. Stacker selection must be specified as a detail operation so that the correct 
card will be selected. Any report formatting you choose is acceptable. 
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~ Use the RPG II look ahead feature. 


-Chapter 5. Controlling Operations In An RPG II Program 


CHAPTER 5 DESCRIBES: 


Additional uses of indicators to control calculations and output. 


Controlling operations on the basis of the next record in a file. 


Manipulating data by moving it from one field to another. 

Saving eet ee and coding in aeieulatins by using Bpanehine and subroutines. 
Special uses of control level indicators. | 

Binary field operations. 


Increasing the speed of RPG I! operations. 


BEFORE READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 


General usage of the following indicators: 01-99, MR, L1-L9, LR, 1P, OA-OG, OV. 
The concept of matching records. 
Coding of arithmetic operations in calculations. 


RPG II object program cycle. 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO: 


Control calculations and output using H1-H9, U1-U8, and Resulting Indicators. 


Condition calculations using OA-OG and OV indicators. 


aes \ : 
Code specifications to move data from one field to another. 


’ Branch in calculations using GOTO and TAG. 


Employ subroutines in calculations using BEGSR, ENDSR, and EXSR. 
Cause an artificial control break and total operations using LO. 


Use control level indicators to perform group printing. 


Control calculations using binary switches. 


_ State advantages of dual input/output areas and correctly code for them. 


Note: You can use the review questions contained in Review 5 at the end of this 
chapter to test your comprehension of each topic in the chapter. Questions are 
grouped according to the topic to which they apply. Answers follow the review 
questions. 
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INTRODUCTION 


There are many ways that you can control the performance 
of RPG I! operations. You have already learned the basic 
elements of controlling calculations and output, especially 
the concept of the RPG II object program cycle and the use 
of indicators to condition specifications. This chapter sup- 
plements those basic concepts by presenting topics that will 
help you improve the performance of your RPG II programs 
and do more complex jobs. 


ADDITIONAL USES OF INDICATORS TO CONTROL 
CALCULATIONS AND OUTPUT 


On the Calculation and Output-Format sheets, you describe 
all the calculations and output to be done in your program. 
Sometimes, all the calculation and output operations must 
be performed on every program cycle. More often, however, 
you want operations done only under certain conditions. 
For example, you may want to perform a calculation or do 
some output only when a control break occurs, do an opera- 
tion only when a certain record type is read, or do certain 
operations only on certain program runs. . 


In columns 7-17 (Indicators) of the Calculations sheet and 
columns 23-31 (Output Indicators) on the Output-Format 
sheet, you can specify when certain calculation and output 
operations are to be done. Some of the indicators that can 
be used, and the conditions they signal, are: 


Indicator Condition 

01-99 Operation is done only when a specific 
record type has been read, or when the 
result of a calculation or the contents 
of a field are as desired. 

MR Operation is done only when records 
match. 

L1-L9 Operation is done only when a control 
break occurs. 

LR Operation is done after all records have 
been read and processed. - 

1P Output record prints only on the first 
page. 

OA-0G; OV. Output record prints only when over- 


flow occurs. 


» §-2 


You are probably somewhat familiar with the use of these 
indicators from previous education, reading, or other topics 
in this book. However, there are other kinds and uses of 
indicators with which you may not be so familiar. This 
section discusses: 


1. Halt indicators used to tell what operations should 
be done on an error condition. 


2.. External indicators used to tell what operations should 
be done for a specific program run. 


3. Overflow indicators used to tell what ca/culations 
should be done when overflow occurs. 


In addition to these new uses of indicators, this section also 
describes conditioning of operations based on the results of 
certain calculations. 


Preventing Operations From Being Done When an Error 
Occurs 


Halt indicators are used to test for an error condition in 
your data. According to RPG I! program logic, a halt does 
not occur as soon as the error condition is found (as soon as 
the halt indicator is turned on). Instead, the program 

cycle is completed before the halt occurs. This means that 
additional operations may be performed in error unless you 
specify otherwise. 


Preventing Calculations When an Error Occurs 


Specifications shown in Figure 5-1 illustrate the use of H1 
to prevent calculations. Tests are made to determine if the 
INSTOK, TOTAL, or ORDER fields on record types 01, 02, 
or 03, respectively, are negative. A negative value in any of 
these fields is an error condition. When an error is found, 
H1 turns on. Since calculations [normally] are done when 
02 and 03 record types are read, conditioning these calcula- 
tions by NH1 prevents them from being done when data is 
erroneous. 


Halt indicators can also be specified on the Calculation 
sheet to test for an error. For example, in Figure 5-2, H1 


_ is set on if the result of operation in line 01 is negative. If 


quantity in stock (INSTOK) is negative after quantity 
shipped (QTYSH) has been subtracted, an error has occur- 
red. H1 turns on and the system will halt after the current 
cycle. 
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Figure 5-2. Testing Result Field for Error Conditions 
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Preventing an Entire Record From Being Written 


Figure 5-3, line 07, shows an output operation conditioned 
so that the record specified will be written only when the 
halt indicator is not on (NH1). When the halt indicator is 
on (H1), it will be bypassed. 


Preventing Fields From Being Written 


Suppose, however, that you do not want to bypass the 
writing of the entire record, but want some fields written 
even when a halt condition occurs. For this case you 
should use the halt indicator to condition certain fields 
within the record instead of conditioning the entire record. | 
This way, when an error occurs, some fields will be written 
and some will not. 


Figure 5-4 shows the specifications which will bypass the 
writing of all fields except DEPT and ITEMNO when an 
error occurs. 


Doing Output Only When an Error Occurs 


It is also possible to condition records or fields so that they 
are written only when an error condition occurs, Figure 
5-5 shows the specifications which do this. 


Using the halt indicator will cause the computer to stop 
after all operations are completed for the record causing the 
error. You may restart processing immediately, however, by 
pressing the start button on the processing unit. 
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Using Indicators Other Than H1-H9 to Bypass Error data on the Input sheet and are then later used to condition 
Conditions . . calculations and output operations (see Figure 5-6). They 

7 do not cause a halt. 
If you are not interested in halting when an error condition <3 
occurs but still wish to bypass the processing of erroneous When you do not wish to halt the program for an error 


data, you may use indicators 01-99 instead. They, like halt condition, you may select cards into a special stacker so that 
_ indicators, may be assigned to check for error conditions in they will not be mixed with valid data cards. Stacker selec- 


tion may be done based on the use of me indicator for an 
error condition. 
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Controlling Which Operations are Done For a Specific 
Program Run 


The chapter entitled Describing and Using Input describes 
how to condition the use of an input file with an external 
indicator so that a program can use different input files in 
different program runs. That chapter also describes how to 
assign external indicators U1-U8 on the File Description 
sheet and how to set the indicators. 


This section describes how external indicators are used on 
the Calculation and Output-Format sheets to condition 
which operations should be done for a specific program run. 


Conditioning Input Files and Related Calculations 


Consider for example, calculations done for a sales analysis 
program. For each item in stock, monthly total sold (SOLD) 
is calculated and then added to last month’s year-to-date 
total (BALFOR) to find the current year-to-date total 
(BALNCE). In the first month of a new year, monthly totals 
should not be added to prior year-to-date totals because 
totals are not carried over from year to year. This last 
statement, the year-to-date addition statement, therefore, 

is not done for all program runs. By conditioning the 
statement with an external indicator, you can control when 
the statement is done. In Figure 5-7, the monthly total is. 
added to prior year-to-date only when U1 is on. 


When one program is written to do two similar, yet unique, 
applications, some calculations may be used for both appli- 
cations, some for only one. Again you may use external 
indicators to control which calculation specifications are 


used for each application. 
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Conditioning Input Files and Related Output Operations 


Consider again the example discussed in the section of Chap- 
ter 2 entitled Conditioning Use of Input Files. Two reports 
were required: sales analysis and inventory (Figure 5-8). 
Since the results are so similar (one report merely includes 


-more information than the other), the ses are coded in one - 


program. 


SALES ANALYSIS 


ITEM NUMBER AMOUNTSOLD- DATE 
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Figure 5-8. Two Similar Reports 


ITEM NUMBER 
46732 7 
8 
2 
1 
150* 
46733 
| | 32* 
| 46739 12 09/15/70 - 
| 7 20 09/16/70 


Two files are available: a MASTER file which shows the 
balance forward for each item, and a TRANSACTION file 
which contains daily records of the number of items sold: 
The sales analysis job requires one file since it just creates 
a list of transactions. The inventory job requires two files 
since, for each item, it subtracts the number sold from the 
balance forward to find the new balance forward. An exter- 
nal indicator was assigned on the File Description sheet (see 
Figure 5-9). Its setting indicates to the program which files 
are to be used. . 
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Because the results differ slightly for each job, different 


output operations are required. When two jobs are coded 
together, you indicate which operations are to be done for 


when U1 is on, the MASTER file is used. This means that 
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indicators in columns 23-31 are satisfied) in each cycle. You, 
therefore, have to tell the computer which operations to do 


forward job. Unless told otherwise, the computer will try 
for each job. 


indicator to signal which files are to be used. You can speci- 
to perform all specifications (provided conditions set by 


each through the use of an external indicator by setting the 
‘fy which output operations should be done in the same 


fications for both jobs. Appropriate heading and detail lines 
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Figure 5-10. Conditioning Output Operations by an External Indicator 
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For example, consider a sales analysis job which does the 
following: 


1. Calculates and records the quantity of each item sold 
during the month. 


2. Updates the year-to-date total of the number of each 
item sold. 


3 Creates a new year-to-date record. 


The input file, organized in ascending order by item num- 
ber, consists of two record types: (1) item cards, and (2) 
summary YTD cards. Each item card represents an item 
transaction. During the job, item cards are counted; and, 

~ when a control break occurs, amount sold is added to the 
year-to-date total found on the summary card. The num- 
ber sold and current year-to-date totals are recorded on the 
sales analysis report, and a new summary card containing 


the. current-year-to-date total is punched. Notice that the 
new year-to-date summary card is stacker-selected into: 
stacker 1, the default stacker for the primary MFCU hopper 
(Figure 5-11, line 11 of the Output sheet). Assume that 
the old: summary card is selected into a different stacker by 
means of an entry in column 42 of the input specifications. 
Thus, the new summary card is automatically placed into 
the item file in preparation for the next run of the program, 
while the old summary card can be easily discarded. 


At the end of the year, new year-to-date summary cards 
should not be punched because the year-to-date total is 

not carried over into the next year. In this case, the punch- 
ing operations should not be done. You can tell the. pro- 
gram whether or not to punch by conditioning the output 
operations and the output file by the same external indica- 
tor. Figure 5-11 shows some of the specifications for the 
job. 
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Always be sure to control which calculation and output 
operations should be done for the job being run by con- 


printed report to a 


group-indicated report or vice versa. Figure 5-12 
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ternal indicator can change a group 


part A, 


shows that a detail line will print for every card. By adding 
an external indicator, you can contro! whether or not the 


detail line will print (Figure 5-12, part B). When U1 is on, 


the line prints; when U1 is not on, it will not print. 


ditioning the operations with the same external indicators 
that were assigned to the file. When you condition input 
files by external indicators, you may. condition output 
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overations if you desire. However when you condition out- 


put files, you must use the same external indicator used for 


If you forget to con- 


dition the records for an output file conditioned by an ex- 


conditioning the output operations. 
ternal indicator, an error will occur. 


Controlling Calculations When Overflow Occurs 


You normally think of using an overflow indicator to con- 
dition total or heading records that must be printed on 


Conditioning Output Operations Only 


every page of a report. But you may also use the overflow 


indicator to condition calculation operations. Any calcula- 
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Assume, for example, that you are preparing an accounts 
receivable report as shown in Figure 5-13. On each page of 
the report, you wish to have a total showing the amount of 
all accounts receivable on that page. You also wish to find 
the total amount of all accounts receivable on all pages. 
Thus at the beginning of each page, you must start accumu- 
lating totals for that page. When overflow occurs you want 
to add the amount of the accounts received (page total) to 
final total, print the page total and then reset the page total 
to zero so that you can start accumulating totals for the 
next page. Only the calculations which are to be done when 
overflow occurs are conditioned by the overflow indicator. 
See Figure 5-14 for the calculation specifications. 


DATE 06/30/0 


CUST NO ACCOUNT NAME 


11886 AABY, SHELLEY 
12093 ACKER, ALVIN 
12128 ADAMS, CINDY 
12206 ADSON, MARION 
12720 ANTON, MONICA 
12803. . AXFORD, JOE 
12815 BAILEY, MARLYS 
12900 BALZUM, GERALD 
13260 BATTEY, ADA 
13265 BEABOUT, ART 
12390 BERGERSON, M. 
14619 | ‘BILSTAD, DON 


Figure 5-13. Report with Page Totals 
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ACCOUNTS RECEIVABLE REGISTER 


Performing Calculations on the Basis of the Results of 
Other Calculations . 


The value of the contents of a field rather than the occur- 
rence of a certain condition can be used to determine : 
whether or not an operation will be performed. You have 
worked with such situations already. For example, you 
have used a field on an input record to determine if 
processing should be done. If the field was positive, you 
wanted to do all calculations; if it was negative, you did no 
calculations. (See Preventing Calculations When an Error 
Occurs. ) 


For the situation just stated the contents of an input field 
determined what calculations (if any) were done. In this 
section, however, emphasis will be placed upon how results 
obtained in a calculation operation can be used to deter- 
mine whether or not other calculations are performed. 


PAGE 1 


ACCOUNTS RECEIVABLE 


INV DATE 
MO/DY/YR 

4/18/0 86.40 
4/18/0 403.10 
4/18/0 345.05 
4/18/0 700.60 
4/18/0 1,253.40 
4/18/0 ‘48.52 
4/18/0 107.05 
4/18/0 345.10 
4/18/0 165.35 
4/18/0 316.05 
4/18/0 43.60 
4/18/0 1,129.02 


4,943.24 . PAGE TOTAL 
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Figure 5-14. Conditioning a Calculation by an Overflow Indicator 


Using the Results of Arithmetic Opérations 


Consider how the result of a calculation can be used to de- 
termine the need for further calculations in a billing pro- 
gram. For each account, it is necessary to first determine 
the amount owed by adding charges and payments (pay- 
ments are recorded as negative numbers) to the balance due 
at the beginning of the month. For any customer owing © 
money at the end of the month, a service charge of 1-1/2 
percent is added to the amount due. If he has credit coming, 
he must be sent a credit memo instead of a bill. Thus a test 
) must be made on the amount due field to determine if it is 


plus or minus. If it is plus, the customer owes money and 


the service charge must be figured before the bill is printed. 
If it is minus, he has a credit and must be sent a credit memo. 
The card for the customer with a minus balance is stacked 
into a special hopper. 


It is later used in a credit memo run. 
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How can you cause a test to be made on the data? Remem- 
ber in Figure 5-1 how you tested for a minus quantity. By 


_ entering an indicator (01-99, H1-H9) in columns 54-59, you 


can test for plus, minus, or zero depending upon where you 
place the indicator. 


For this program; indicator 99 is placed in columns 54-55 

to test for a plus condition (see Figure 5-15). When a control 
break occurs (all transactions for one account are processed) 
and when 99 is on, the 1-1/2 percent service charge is found 
and added to amount due (AMTDUE) to find total amount 
due. 


If indicator 99 is off (no amount due) when the control 
break occurs, these last two operations are not performed. 
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™. @ Figure 5-15. Conditioning Calculations by an Indicator Set as a Result of an Arithmetic Operation 
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The result of any arithmetic operation (ADD, SUB, MULT, 

DIV, Z-ADD, Z-SUB, MVR) can be tested by specifying re- 

sulting indicators i in columns 54-59, The resulting indica- 

tors which are set as a result of the test can condition those 
operations which are to be performed on the basis of the re- 
sult of that test. 


Using the Results of Compare Operations 


In a compare operation (COMP), fields or literals of the 
same type (alphameric or numeric) are compared to each 


other to determine their relationship to each other. Indica- | 


tors entered in columns 54-59 are used to indicate whether 
the field or literal in Factor 1 is higher than, lower than, or 
equal to the field or literal in Factor 2. 


The results of a compare can also contro! which calculations 
should be done next. For example;:-when doing an inventory 
and reorder. application, the compare operation (COMP) 

is used to determine if any item needs to be reordered. In 
the example shown in Figure 5-16, the field called MIN 
(minimum) contains the critical reorder point. The field 
ONHAND is compared to MIN. If the amount on hand is 
less than or equal to MIN, indicator 99 ison, The reorder. 
quantity is calculated by subtracting amount on hand from 
the number in the field called MAX which contains the 
maximum number which should be in stock. If amount on 
hand is greater than MIN, no reordering need be done and 
this calculation is not done. 
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Using the Results of the Test éone (TESTZ) Operation | 


Another operation code, TESTZ, is available to test data 


during calculations so that you can determine which cal- 
culation to do next. _TESTZ tests only the zone portion of . 
the leftmost character of an alphameric Field. TESTZ does 
not test specifically for plus, minus, or zero; high, low, or 
equal. ‘Rather, it tells you into which group of zones the 
zone tested falls: | 


@ The zones of the character & (ampersand), A- cause 
the Plus indicator entered in columns 54-55 to be turned 
on. 


@ The zones of the characters \ (bracket), - (minus), and 
‘J-R cause the Minus indicator entered i in columns 56-57 
to be turned on. 


®@ The zones of all other characters cause the indicator 
entered in columns 58-59 to be turned‘on. 


The test zone operation could prove very useful in a large - 
billing application. Consider the case of a company which _ 
has so many accounts that billing must be divided. Customers 


. whose last names are in the first part of the alphabet are 
billed on the 15th of the month; all others are billed at the 


last of the month. The master file used in billing is organized 
in ascending order according to account number. 


The records in this file could be sorted by name so that you 
could divide the file for billing. However, this.file is used 
so often for other purposes that it is a waste of time to ... 
repeatedly sort it according to name and then sort it again. 
according to account number. . 
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Figure 5-16. Conditioning Calculations by an Indicator Set as a Result of a Compare Operation 


Lo) 


A better way to do the billing is to test the name field in 


each record to see in which part of the alphabet the name falls. 


During the first of the month, if the last name begins with 
letters A-I, you wish to find amount due. TESTZ will test 
the first letter in the field and tell you in what part of the 
alphabet it is. Figure 5-17 shows the calculation specifica- 
tions necessary to bill customers whose last names fill into 
category A-l. 


IBM Interna ‘onal Business Machine Corporation 


Factor 1 Operation 


I~ Control Level (LO-L9, 
@ LR, SR, AN/OR) 





Naturally at the end of the month you will want to bill the 
rest of the customers. But you don’t want to write another 
program for end of the month billing. So you write one 
program to do both jobs and use external indicators to con- 
dition the specifications for each job (see Figure 5-18). 
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Figure 5-17. Conditioning a Calculation by an Indicator Set as a Result of the TESTZ Operation 
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Figure 5-18. Using TESTZ and External Indicators 
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Yuu can use TESTZ to test for any special code you set up 
by using the zone of a character. This is most often done 
when you have no space on your records for any other kind 
of identifying information. For example, when establishing 
a code for the percentage of commission received by each 
salesman, you could use the & to indicate 6 percent and 
the minus (-) sign to indicate 15 percent. You would, of 
course, have to punch this code in the leftmost position of 
a numeric field because this is the position tested by the 


SALESMAN - 
2 | 
Whose number is 17657778 


‘Who éarns 15% commission 


Has 17657778 punched - 
in SALSNO field 





7 
e 


t 23 45 6 7 & 9 WM 12 13 4 15 86 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 
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TESTZ operation: . Figure 5-19 shows how the code is 
placed in the field containing salesman number. However, 
you must define the field as alphameric since the TESTZ 
operation can mouly be rene’ onan aipoamete ele 
Figure 5-20 Shaws the TESTZ aed on the SALSNO a : 
man number) field, which contains the commission code, 
in order to find rate of commission. The results of the test 
determines what other calculations will be done. 
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Figure 5-19. Punching a Code 
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Figure 5-20. Testing a Field to Determine a Code 
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CONTROLLING OPERATIONS ON THE BASIS OF THE 
NEXT RECORD INA FILE 


Sometimes, calculations to be performed may depend upon 
information in the next record or on the type of the next 
record to be processed. For example, in a certain kind of 
program, you might want to bypass calculations for the cur- 


rent record if you know the next record in the file is identical. 


The RPG II language has a special feature called /ook ahead, 
which extends the basic RPG II logic. It will allow the com- 
puter to look at information in the next record to be 
processed while it is processing the current record. This 
means that information in record B can be used while record 
A is being processed. By using this feature, you can 

write a program that uses information from the next record 
available for processing. _ 


Look ahead can be used with card, tape, or disk input files. 
This section discusses look ahead with card (MFCU) and 
disk files. For MFCM, tape, and other files, the concept 

is similar. 7 






Stackers 


Hopper 








Read 
Station 


a Figure 5-21. The Look Ahead Function with a Card File 







Primary 
Hopper 


Processing Card or Disk Files 


MFCU Files: (Refer to the representation of the MFCU 
card path in Figure 5-21 during this discussion.) As Card : 

A is read, data recorded on it is transferred to. the input 

area. The card then moves on to the wait station. Accord- 
ing to the RPG II program cycle, information is transferred 
from the input area to the processing area right before de- 
tail time. At detail time, then, calculations can be done on 
data from the card path which is in the wait station (Card A). 


However, when look ahead is specified, another card (Card 
B) is read before detail time operations are performed in 
the current cycle. Card A is stacked and information from 
Card A is moved to the processing area. Then information 
on Card B just read is transferred to the input area and is 
available for use while processing Card A, now in the 
stacker. eee 


Print 


bat Station 













Punch 
Station 


Card A is stacked and data from card A 
is moved to the processing area. 





re) 
Primary 
Wait Station 


Secondary 
Wait Station 





~ Before card A is processed, data from 
card B is read into the input area, 
where it is available while processing 
card A. 


BL CO 
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Disk Files: Figure 5-22 shows processing of three of the Record Processed Records Available 
records from two disk input files, one primary and one , 
secondary. The records available for look ahead during the P1 P2 and S1 
processing of these records are: : 


P2 : P3 and S1 
$1 P3 and S2 
PRIMARY FILE | SECONDARY FILE (A) 


Read first record el eal ci 





Read first record 
_ from secondary file (S1). 


from primary file (P1) 









Area into which records 
are read (read area). 


Area into which records 
are selected for 
processing (process area). 


cs second 


record from 
primary file. 








Process Area 


from primary file 
for processing. 


Figure 5-22 (Part 1 of 2). Records Available for Look Ahead: Two Input Files 
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Jn general, when the record being processed is from an in- 
put file, the next record in the input file is available as are 

) the records which were read but not processed from the 
other files. 
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Figure 5-22 (Part 2 of 2). Records Available for Look Ahead: Two Input Files 
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Checking for’ ne 


Duplicate’ records or records with ie fields are some- 
times considered erroneous. Only one of the cupllcatets 
should be: used for the. jobs. ae a 


Consider, f for penne. the case of a company which has a 
large turnover in inventory items. Quite frequently new 
items are added and others deleted from the inventory. A 
number for a deleted part is to be assigned to a new part. 
Some mistakes have occurred, however, and one part num- 
ber has been assigned to two different items. Asa result of 
this error, inventory balances for these items have not been 
updated correctly, and errors have been made on customer 
invoices. If this situation is possible, a regular check anoule 
be made for duplicate part numbers. 


Each month, a report is created showing the complete in- 
ventory. All part numbers: are listed on the report. You 
could look through the report to check for duplicate part 
‘numbers, but it would be easier and more accurate if you 
could add a few specifications that would check for dup- 
licates and indicate on the report which item numbers are 
duplicate. 
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Figure 5-23. Look Ahead Specifications. 
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By using the look ahead feature you have access to informa- 
tion that is coming up. You can then use this information 
to determine what operations to do. If you are processing 
a record with part number 64322, and you know that the - 
next record also has part number 64322, you can ‘print ‘a - 
message indicating duplicate’ part numbers, then halt. But, 
if you are processing the record with part number 64322: 
and you do not know that the next record also has part 
number 64322, you can do nothing special because you are 
not aware that you are processing a record which contains 
a duplicate entry. 


Writing Specifications for Look Ahead 


Any field which you want to look at in the next record to 


_ ~ be processed must be defined as.a look ahead field. If that 


field is also used in normal processing (other than as a look 
ahead field), it must be defined in the normal way also. 
Thus, most look ahead fields will be specified twice. 


Figure 5-23, lines 01-05, shows specifications needed to 
describe the input file used in preparing an inventory listing. 


~ When checking for duplicates, PARTNO is the field you 


want to use when looking ahead at the next record; there- 


fore, PARTNO must be defined as a look ahead field. The 


specifications in Figure 5-23, lines 06-07, do this. 
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All look ahead fields must be defined as being in a record 
type different from the others defined. This is done by | 
using a unique alphabetic sequence entry in columns 15-16. 
No record identifying indicator (01-99) can be used. A . 
double asterisk (**) is placed in columns 19-20 to specify 
that the fields described in the following lines are look _ 
ahead fields. Field location is also specified for look ahead 
fields. 


(NEXTNO) 


INPUT AREA 


12643 
(PARTNO) 





Every look ahead field must be named, but the name given 
must be different than when it was described as a normal — 
input field. The same field is given two names so that you 
can distinguish between the field on the record being 
processed and that same field (the look ahead field) on the 
record that is to be processed next (Figure 5-24). 


NEXTNO refers to 
Positions 1-5 in the 
record to be processed next. 


-PARTNO refers to positons. 
1-5 in the record currently 
processed. 


‘Figure 5-24. Look Ahead Field: A Field with Two Names . 
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Using Look Ahead Information | 


Now that you have specified the look ahead field, you can 
use it as you would any other field. The only exceptions 
are that you cannot use it as a result field in calculations, 
nor can it be blanked after for output. 


In the listing program, you have to make a comparison 
between part numbers from two records. If PARTNO on 
the record being processing is the same as NEXTNO on the 
next record to be processed, you wish to print a message 
indicating duplicate entries. If the PARTNO and NEXTNO 
fields do not match, there are no duplicates for that pave 
number, and the item is merely listed. 


Figure 5-25 shows specifications for the program. The opera-: - 


tion in line 01 of the Calculation sheet compares the part 
number on the record being processed (PARTNO) to 
Barts number on the record coming next (NEXTNO). 
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RPG CALCULATION SPECIFICATIONS 









Factor 2 


r| a 
re CHEE 


they are equal, indicator 07 is turned on. Notice. on the 
Output-Format sheet that when 07 is on, the word dup- 
licate is printed. 


The SETON and SETOF operations in lines 02- 04 of the .. 
Calculation sheet are used so that the computer will in- 
dicate a duplicate when the second record having the dup- 
licate part number is processed. | . 


Consider, for example, records A1, A2, and B. The first 
two records are duplicates; the third is not. When A1 is 
processed, the program looks ahead to A2 and, by com- 
paring, knows that A2 is the same as A1. When A2 is 
processed, the program looks ahead to B. The compare will 


say that A2 is not a duplicate since it does not match B1. 


But A2 really is a duplicate because it is the same as A1. 
Thus, when processing A1,-you have to set an indicator 
which will be on when A2 is processed and which will in- 
dicate that A2.is a duplicate since it matches the previous 
record. | 
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Figure 5-25. Using Information from the Look Ahead Field to Check for Duplicates 


When PARTNO equals NEXTNO, 07 turns on. This, in 
turn, causes indicator 51, which is used to indicate that a 
duplicate record is processed, to turn on. During the next 
program cycle, the compare does not indicate duplicates; 
therefore 07 is not on. But 51 /s on, meaning that the rec- 
ord being processed is a duplicate since the part number on 


it matched the part number on the previous record. There- - 


fore, 07 is set on. Remember 07 conditions those output 
operations which are to be done for duplicates. , 
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Indicator 52 is set on in line 03 to indicate that the last 
duplicate record is being processed. Indicator 52 then con- 
ditions line 04 so that indicator 51 will be set off and not 
indicate duplicates in the following cycle. Figure 5-26 
shows the program logic for this job. 
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) Figure 5-26 (Part 1 of 3). Logic for Look Ahead 
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Figure 5-26 (Part 2 of 3). Logic for Look Ahead 
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eo Move data from record selected 
into processing area. If Look 
Ahead is specified, read another 
e record. If cards, the first card 
is stacked. j 


Figure 5-26 (Part 3 of 3). Logic for Look Ahead 
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Doing Special Operations When There is Only One Record 


in a Group MONTHLY CHARGES 

It is often important to know if and when you are process- _| ACCTNO NAME CHARGE 

ing the only record in a group. The program described in the 47653 JILL ARNDT 497 

following paragraphs is such a case. 5.99 oe lines 
23.87 


A report is prepared showing charges made by customers 
during the month (Figure 5-27). The input file is organ- JILL ARNDT 34.83 * Total 
ized in ascending order by customer number. During the 
month some customers will have made one charge; others 
several. JOAN BOND 7.42 Detail 


NANCY BENNET 87.93 * Total 


When only one charge is made per customer, the total line 
is nearly a duplicate of the only detail line. In this case, 
you do not need to print both the detail and total line be- Figure 5-27. Format of Monthly Charges Report 
cause the total line will do. 





Whenever a record is read, the current ACCTNO field is 
compared to the one coming up. If the fields are equal, you 
know you are processing a record that is not the only one 
in a group. Therefore, a detail line should be printed. If 
the ACCTNO fields are not equal and this is the first time 
the present account number has been encountered, the cur- 
rent record is the only one in the group, and the detail line 
should not print. Figure 5-28 shows the specifications for 
the program. 


But how will you know during any one program cycle 
whether the current record is the only one in a group? 

You can find out by looking at information on the next 
record. Remember, any time information from the next 
record is necessary to determine how to process the cur- 
rent record, you must use the look ahead feature. Account 
number is established as a look ahead field in this program. 
Any look ahead field specified applies to all record types. Thus 
each record read contains information that will be looked at 
before the record itself is processed. By looking ahead into 
this field you will know whether or not the next record 

to be processed is part of a new group. . 
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Doing Special Operations for the Last Record ina Group 


In some.programs, jt may be necessary to do special opera- 
tions on the last record of a control group. This is because, 
unless the last record in the control group is of a different 
' type (have different record identification), it is impossible 

, to know when you are processing the last record in the 
group. When all records are of the same type, you have to 
know what is on the next record before you know whether 
or not you are processing the last record in the group. To - 
‘look at information in the next record, yeu must use the 
' look ahead feature. . 


- Figure 5-29 shows four records which are to be processed. 
The first three belong to one control group; the fourth is 
the beginning of the next group. The last record of the 
group (the third record in this case) requires special 
processing. In order to know when the last record in the 
group.is to be processed, you must look at the account 
‘number in.the next record. When it is different, you know 

that the last record in the group is being processed. 


ae) 


ie 
Additional Points to Consider About Look Ahead 


You must consider the following things when yous are 
(planning to use look ahead: 


e When aes is used with a combined or update 
file, and that file is the only input file in the program, 
the field looked at is not on the next record, but on 
the record currently being processed. Therefore, there 
is little use for look ahead with update or combined 
files ina single file program. In a program with multiple 
-input- type files, look ahead fields can be useful in update 
and combined files. For example, if two files with: look 

: ahead. fields are being processed — an input file and a 

en combined file. (or update file) — look ahead fields in the 

; ‘combined file are available as the input file is being 

"processed (see Figure 5-22). 


@© Look ahead is never used with chained, demand, or out- 
put files. 


@ Only one look ahead record type specification may be 
used for a file. _There may be several fields listed under 
that one. record ‘ype ‘specification however, 


@ Any look. siteed lelds specified apply to all types of rec- 


ords in the file. Therefore, all records read from the file 
will be treated as if they have look ahead fields. 
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47654 
(Account field 
specified also as 

a look ahead field). 






In the processing of 
this record, the Look 
Ahead feature shows . 
that the next account 
number is different. 
Therefore, this is the 
‘last record of a group 
‘and as such requires 
special operations. 


Figure 5-29. .Using Look Ahead to Find Last Record ina Group 


MOVING DATA 


You can instruct the program to manipulate data in many 


- different ways. You can cause data to be added, subtracted, 


multiplied, compared, tested or divided. You can also cause 
data to be moved, When data is moved, a copy of the data 
in one field is transferred to another field. In the.process 
of transfer, it may or may not be changed depending upon 
your specifications. . 


You may wish to move data for many reasons, including: 


1. To save information from a field. 


2. . To separate one field into 2 or more parts. 


gas To change a numeric field into an alphameric field or 


vice versa. 


The preceding topics will be discussed later in this section. 
First, however, you must learn how to use the move opera- 
tion codes. 


Specifications for Moving Data 


Two operation codes can be used to move data: MOVE or. 
MOVEL. For both operations Factor 2 and the Result 
Field are always used. Factor 2 may be either a field or 
constant. Any conditioning indicators may be used. How- 


ever, Factor 1 and resulting indicators may not be specified. 


The MOVE operation code moves a copy of characters 
starting from the rightmost position of Factor 2 into the 
rightmost positions of the Result Field. As a result of the 
move, the contents of the Result Field are changed, but the 
contents of Factor 2 remain the same. Figure 5-30 illus- 
trates the MOVE operation. 


The MOVE operation code 
moves a copy of characters 
starting with the rightmost 
position of Factor 2 into the 
rightmost positions of the 
Result Field. 


When Factor 2 and the 

Result Field are the same length 
all characters in Factor:2 - 

can be moved. Movement starts 
with rightmost character of — 
Factor 2 


Factor 2 


1234567 


Result Field 


Factor 2 When Factor 2 is longer than the 
Result Field, only the exact num- 
ber of characters needed to fill 

the Result Field are moved from 
the rightmost positions of Factor 2 


into the Result Field 


Result Field 


When Factor 2 is shorter than 
the Result Field, all characters in 
Factor 2 are moved into the 
rightmost positions of the 
Result Field. Ail characters in the 
Result Field to the left of those 
moved in from Factor 2 remain 
. the same as they were 
before the move. 


Factor 2 


1234567 


Result Field Sieh 





Figure 5-30. MOVE Operation Code 
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If the Result Field is the same length as Factor 2,.all char- 
acters in Factor 2 are transferred. However, if the Result 
Field is shorter than Factor 2, only the number of charac- 
ters needed to fill the Result Field are transferred. On the 
other hand, if the Result Field is longer than Factor 2, all 
characters in Factor 2 are moved to the rightmost positions 
of the Result Field. The excess leftmost characters of the 
Result Field remain unchanged. 


The MOVEL operation is just the reverse of the MOVE 
operation; it moves a copy of the characters starting from 
the /eftmost position of Factor 2 into the leftmost posi- 
tions of the Result Field. Figure 5-31 illustrates the MOVEL 
operation. 


The MOVEL operation code 
moves a copy of characters starting 
with the leftmost position of 
Factor 2 into the leftmost 
positions of the Result Field. 


When Factor 2 and the 

Result Field are the same length 
all characters in Factor 2 

can be moved. Movement starts 
with the rightmost character of 
Factor 2. 


Factor 2 


ABCDE 
fy 


ABCDE 


Result Field 


Factor 2 When Factor 2 is longer than the 
Result Field, only the exact num- 
ber of characters needed to fill 
the Result Field are moved from 
the leftmost positions of Factor 2 


into the Result Field. — 


Result Field 


Factor 2 When Factor 2 is shorter thgn 

the Result Field, all characters in 
Factor 2 are moved into the 
leftmost positions of the 

Result Field. All characters in the 
Result Field to the right of those 
moved in from Factor 2 remain 
the same as they were before 

the move. -: 


Result Field 


Figure 5-31. MOVEL Operation Code 
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Figure 5-32. Data in Storage 
5-30 2 


Saving Information From a Field by Move Operations 


Any information in fields specified as input fields is nor- 
mally only available for one program cycle. Each time a 
record is read, information from the fields on the new rec- 
ord replaces that which was there from the previous record 
(see Figure 5-32). 


There are times, however, when you wish to save informa- 
tion from a record so that you can have it available in the 


next program cycle. For instance, you'may want to check » 


the contents of a field in order to determine if a file is in 
proper sequence or if it has duplicate entries. In order to 
do this, you must have the data from two fields, the field 
from the record just read and the field from the record 
read in the previous cycle. 


Consider the problem of checking the sequence of, and 
finding duplicate entries for, the file shown in Figure 5-33. 
Sequence is to be based on ACCT (account number) and 


must be ascending. Any duplicate or out-of-sequence rec- 


ords are to be flagged. 


The program must compare the ACCT fields from two 
records: the record currently being processed and the pre- 
vious record. The current account field should always be 
higher than the previous account field. Would the specifi- 
cations in Figure 5-34 do the job? They would not, be- 
cause in one program cycle the field named ACCT always 
has the same information in it. This information is taken 
from the record just read. Just because you use the name 
twice, you won’t get two different ACCT fields. 


Record out of sequence 





Duplicate 
Records 





Account Field 


Figure 5-33. Input Field Sequence 
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Figure 5-35. Moving Data to Save It 


5-32 
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Therefore, each time a record is read, you must save the in- 
formation from the ACCT field so that it is not destroyed 
when another record is read. This you can do by moving 
ACCT into another field. (Figure 5-35 illustrates this con-: 
cept.) . 


Figure 5-36 shows the specifications needed to do the job. 
Assume that you move ACCT into a field called SAVE. 

The first step is to compare ACCT with SAVE (which con- 
tains the previous ACCT data). The second step is to move 
ACCT into SAVE. In the first program cycle, SAVE will 
contain all zeros since all numeric fields are set up with 
zeros before the first record is read. In the next cycle, 

and all cycles thereafter, SAVE will contain the ACCT field 
from the previous record. 


Maybe you are wondering why you would ever want to se- 
quence check by calculations instead of using the RPG II 
automatic sequence checking function which is done merely 
by specifying a match field. The answer is that, with RPG 
Il automatic sequence checking, any out-of-sequence card 
will cause a ha/t. If you do not wish to halt, but merely 
wish to indicate out-of-sequence or duplicate cards, then 
you must do your own sequence checking. You could also 
use the look ahead feature, since both look ahead and the 


use of moves in calculations give essentially the same results. 


Separating One Field Into Two Parts 


A company has designed its part numbers to contain two 
different kinds of information. The basic part number is 
contained in the first three characters. The remaining five 
characters contain the price. For example, in the part num- 
ber 65J00498, the basic part number is 65J and the price is 
$4.98. When preparing invoices, it is necessary to multiply 
unit price times quantity to find the total price. You don’t 


want to multiply the whole part number field times quan- 
tity just because the part of the field contains unit price. 
Somehow, you must separate price from the rest of the 
field. 


To do this you again use a move operation. You cannot - 
move the whole field into another field as was done in the 
previous example. This merely creates a second field iden- 
tical to the first. You want only the last five characters. 

Therefore, you must move the field into a 5-position field. 


- This will limit the move to five characters (see Figure 5-37). 
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Figure 5-37.. Separating the Price from the Part Number 


(Using MOVE) 
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In this case, the MOVE operation was used, Why wouldn't 
the MOVEL operation work as well? Couldn‘t you move 
left into a 3-character field to separate the price from the 
rest of the part number? Remember that a move leaves the 
original field as it was before the move. MOVEL does not 
remove the first three characters from the original PARTNO 
field. It merely copies them. You still would not have the 
unit cost by itself. But you would have the part number by 
itself (see Figure 5-38). | 
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Figure 5-38. Separating the Part from the Part Number (Using MOVEL) 
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Changing Field Type (Alphameric or Numeric) 


The part number field contains both numeric and alpha- 
betic characters (see Figure 5-38). If you want the pro- 
gram to work with the zone portion of a character {as it 
must to get the letter J), you have to define the field as 
alphameric (blank in column 52 of the Input sheet). How- 
ever, you cannot use an alphameric field in arithmetic cal- 
culations. To find total cost, you must multiply unit price 
by quantity. This is an arithmetic operation; thus the field 
must be numeric. 


What do you do if you need one field to be defined as both 
alphameric and numeric? You could define the field twice — 
once as numeric and once as alphameric. Of course, you. 
would have to use two names for the same field since every 
field defined for one type of record must have a unique 
name. 


You may also use a move operation to change a numeric 
field into an alphameric field or vice versa. You can change 
fields by: 


1. Moving an alphameric field named in Factor 2 into a 
numeric Result Field. 


2. Moving a numeric field named in Factor 2 into an 
alphameric Result Field. 


Figures 5-39 and 5-40 give the rules for and examples of 
the various types of moves you can make to change a field 
type. Figure 5-39 illustrates the MOVE operation and Fig- 
ure 5-40 the MOVEL operation. Ifyou do not understand 
results obtained in the low order positions, see the chapter 
entitled Working With Data Structures. 





Factor 2 same length as Result Field 


Factor 2 


When moving an alphameric 
field into a numeric field, 

the digit portion of al! characters 
is moved. The zone portion of 
the rightmost character is also 
moved and used as the sign. 





+ 
123456 





Result Field 


Factor 2 

When moving a numeric field 
into an alphameric field, all 
digits are transferred. The sign 
(zone portion) of the rightmost 
character is also moved. 





Result Field 


Factor 2 longer than Result Field 


Factor 2 
When moving an alphameric 
field into a numeric field, the 
digit portions of only the number 
of characters needed to fill the 
+ Result Field are moved. The zone 
3456 portion of the rightmost character 
Result Field is also moved and used as the sign. 
Factor 2 ‘ 
+ When moving a numeric field 
into an alphameric field, only the 
eee number of digits needed to fill 
< the Result Field is moved. The 
Prey sign of the rightmost character 
is also moved. 
Result Field 
Factor 2 


When moving an alphameric 
field into a numeric field, the 
digit portion of all characters 

is moved. The zone portion of 
the rightmost character is also 
moved and used as the sign. 

All characters in the Result Field 
to the left of those just moved 

in remain the same as they were 
before the move. 


ABCDEF 
| 









| 


Result Field 
Factor 2 


UT+ 
. When moving a numeric field into 
an alphameric field, all digits are 
moved. The sign (zone) of the 
rightmost character is also moved. 
All characters in the Result Field 
to the left of those moved in 


Result Field 


remain the same as before the move. 


Figure 5.39. MOVE Operations Involving Fields of Various 
Lengths and Types 
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When moving an alphameric 

field into a numeric field, the 
digit portion of all characters is 
moved. The zone portion of the 
rightmost character is also moved 
and used as the sign. 





Result Field 
Factor 2 : ogi 
a When moving a numeric field into 
873214 an alphameric field, all digits are 
moved. The zone portion of the 
rightmost character is also moved. 
Result Field 
| Factor 2 longer than Result Field | 
Factor 2 


When moving an alphameric field 
into a numeric field, the digit 
portions of only the number of 
aN characters needed to fill the Result 
<" (zone of 0 Field are moved. The zone portion 
becomes sign of the rightmost character is also 
of Result Field) moved and used as the sign. 





ABCMNO 
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Result Field 
Factor 2 


873219 


(zone of O 
becomes sign 
of Result Field) 


When moving a numeric field 
into an alphameric field, only the 
number of digits needed to fill 
the Result Field is moved. The 
sign of the rightmost character 

is also moved. 






Result Field 


——E——_—_—_—_ ee ee ee 


Factor 2 shorter than Result Field | 


When moving an alphameric 





Factor 2 field into a numeric field, the 
digit portion of all characters 
is moved. All characters in 
ea ee the Result Field to the right 
é of those just moved in remain 
1234567 the same as they were before 
! the move. Thus the sign of 


Result Field 
Factor 2 


873216 
< , 
8732197 


Result Field 


field does not change. 






When moving a numeric field 

into an alphameric field, all digits 
are moved. All characters in 

the Result Field to the right of 
those just moved in remain as they 
were before the move. 


Figure 5-40. MOVEL Operations Involving Fields of Various 
Lengths and Types ; 
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In order for the letter in the part number ever to be read, 
compared, or printed, the field ..1ust be defined as alpha- 
meric. When it is time to multiply price times quantity, the 
price portion of the field must be numeric. Therefore, when 
using the MOVE operation to separate the unit cost from 
the rest of the part number, you should, at the same time, 
change the alphameric unit price into a numeric unit price 
by moving it into a numeric field. To define a numeric 
field, you must specify decimal position along with field 
length (see Figure 5-41). 


If the 5-character unit cost had preceded the part number 
(for example, 0049865J), you would then use the MOVEL 
operation to get the unit cost alone. Remember, however, 
that the zone of the rightmost character is used for the sign 
of the field (see Figure 5-40). The zone of the character J 
is a minus sign. The price will appear as negative. This you 
would not want. 
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The price section 
of the part number 
| Card Electro Numbe field is changed to 

| a numeric field by 
moving it into a 
numeric field. Two 
decimal places were 
specified to show 
the cents portion 
of the field. © 
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Figure 5-41. Changing a Field by the MOVE Operation 


When using move operations to change an alphameric to a 
numeric field, keep in mind the kind of sign (plus or minus) 
each character will give you: a - (minus sign), or J through / 
R gives a minus sign; the rest give a positive sign. If you are. 
aware of this, you will not get unexpected results. Since no 
sign is involved in an alphameric field, you don’t need to 

worry about the sign when changing a numeric to an alpha- 
meric field. 


BRANCHING IN CALCULATIONS 


The detail and total operations written on the Calculation 
sheet are normally executed in the same order as they are 
written. For each record selected for processing, the detail 
operations are performed sequentially from beginning to 
end. If the record selected for processing causes a contro! 
break, the total operations are performed, in the order 
specified, before detail operations. 


There are many times, however, when it is necessary that 
operations not be performed sequentially. For example, in 
one cycle you may wish to skip some calculations or to do 
others several times. In this section you will learn to alter 
the sequential processing of calculations using the most 
efficient coding. 


Bypassing Calculations 


So far you have been bypassing operations by the use of 
indicators. For each calculation conditioned by indicators, 
a check is made to see if the condition set by the indicators 
is satisifed. (When several sequential operations are condi- 
tioned by the same indicator(s), the test is only made on the 
first operation.) If the condition is satisfied, the operation 
is performed. Calculations are bypassed or omitted when 
conditions are not satisfied. When bypassing calculations 
in this way, the program has to check the conditions set for 
the operations to determine whether or not to do them. 
This requires time and storage space inside the computer. 


Another way to bypass calculations is to branch around 
them. With the latter method, the indicator setting for 
each operation is not checked. When the branch is taken 
around operations, the operations are just skipped (see , 
Figure 5-42, insert A). | 


Two operation codes are used for branching: GOTO and ~ 
TAG. GOTO is the code which causes a branch to another 
spot in the calculations. The TAG operation gives the name 
and location of the spot to which the GOTO operation 
branches. GOTO causes a branch; the TAG code does 


nothing but act as a nametag. : ee 


Figure 5-42, insert B, shows how GOTO and TAG are speci- 
fied. GOTO signals a branch to the spot named in Factor 2. 
This name must also appear in the TAG statement, where 

it is entered in Factor 1. The rules for forming a name for 
GOTO and TAG are the same as those for forming any field 
name. 


A GOTO statement can be conditioned by an indicator, but 
a TAG cannot. When a GOTO is not conditioned, a branch 
occurs in every program cycle. 


In the example shown in Figure 5-42, the GOTO operation 
is done only when 01 is on. If the condition is satisfied, a 
branch is taken to that point in the program where the same 


NEXT is found. NEXT is the name of the TAG statement. 


Any operations between the GOTO statement and the TAG 
statement (those specified in lines 03-05) are skipped. TAG 
does nothing, so the next operation performed is the SUB 
instruction in line 07. 


if branching were not done, the three operations skipped 
by the branch would have to be conditioned by NO1 so 


- that they would not be done when 01 turned on. And, of 


course, a check would have to be made in each program 
cycle to determine if the operations should be done or not. 


There are many situations in which branching will help you 


write more efficient and effective programs. The following 
sections will explain more fully the use of GOTO and TAG. 


Skip these 


a I a operations if 


01 ison. 
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Branching When Different Record Types Require Different Consider the use of such a branching structure in a sales 


Operations . analysis program. Each day the manager of a retail store _ 

| . wishes to know total cash sales, total charge sales, and total ~ 
When doing different operations for different record types, refunds. The input file, arranged in ascending order by ac- 

you use the record identifying indicators to show what opera- count number, contains four different record types: 

tions should be done for each record type read (see Figure . 

5-43). When you have several record types and each type 1. Charge records record total charges and refunds (if 
requires several operations, you can see that many condition- any) for a particular account. 


ing indicators are necessary. s th 
Zi Payment records record any payments received. They 


For situations like this, you can branch directly to the set are included in the file, but are not needed in this job. 
of calculations which should be done for the record type s i 

just read. When those calculations are done, you can then 8. Refund records record any refunds made for an ac- 
branch to the end of all calculations. This eliminates check- _. count. No cash and charge sales were made by this 
ing operations to see if a set of calculations should be done customer. 

for the record type being processed. In fact, record identify- 

ing indicators do not need to be specified for the individual 4, Cash sales records record total cash sales and cash re- 
operations. Figure 5-44 shows the recommended branching funds (if any) for a particular account. | 


structure used for different record types which require dif- 
ferent operations. Using this structure not only makes your 
programs more efficient but also makes them easier to under- 
stand and document. 
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Figure 5-45, insert A, shows the input specifications for all 
record types. Notice the record identifying indicators as- 
signed to each record type. . 


In the calculations, all charges, cash sales, and refunds are 
totaled. If a refund is given along with the cash or charge 
sales for an account, the amount of the refund is subtracted 
from the amount of the cash or charge before the cash or 
charge is added to the total. Figure 5-45, insert B, shows 
the calculation specifications for the job. As you see, the 
recommended branching structure was used. If a charge 
record (type 01) is read, a branch is taken to ROUTO1. Cal- 
culations specified in lines 06-08 are performed. Then a 
branch is taken to END, for there are no more operations to 


do for that record. Branching for record types 03 and 04 is — 


handled in the same way as for record 01. However, when a 
payment record is read (02 turns on) no calculations are per- 
formed because this job is not concerned with payments. 
Therefore, a branch is taken to END. In this way all calcula- 
tions are bypassed. They are not even checked to see if con- 
ditions established by indicators are satisfied. 


Branching in a Matching Records Job 


Suppose that you are doing a matching record job which re- 
quires that all calculations be done when records match. 

All specifications can be conditioned by MR (see Figure 
5-46), or GOTO and TAG can be used to branch around all 
calculations when records do not match (see Figure 5-47). 
In this example, GOTO is conditioned by NMR. When rec- 
ords do not match, all calculations are skipped and a branch 
to END occurs. 
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Figure 5-47. Branching in a Matching Records Job 


Branching When An Error Condition Occurs 


Branching is an easy way to bypass all calculations which 
should not be performed when an error occurs. Figure 5-48 


shows an example of this. 
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Figure 5-48, Branching When an Error Occurs 
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Branching at Different Points in the Program 


Within one program you may use any number of GOTO 

and TAG operation codes. One or more GOTO statements 
may have the same name (Figure 5-45, insert B, lines 02, 09, 
and 12). However, each TAG must have a different name. 

If two TAGs had the same name, your program would not 
know where to branch. 


Branching at Detail and Total Time 


You may branch from one detail calculation to another de- 
tail calculation or from one total calculation to another 
total calculation. However, you cannot branch from a de- 
tail to a total calculation or vice versa. 


Branching Backward 


So far, you have learned only about branching forward in 
order to skip statements that you do not wish to perform. 
The GOTO statement can also branch backward. In this 
way you can go back to statements that were already done 
in order to do them again. 


Doing the same statements over and over again in one pro- 
gram cycle is called /ooping. The statements done several 
times in one cycle, plus the branching statement, make up 
the /oop. Figure 5-49 shows the basic structure of a loop. 


When would you want to branch backward? Suppose you 
want to print out several mailing labels for each customer 
by using the EXCPT operation code (see Repetitive Output 
(EXCPT Operation) in the chapter, Programmed Control of 
Input and Output for an explanation of the EXCPT opera- 
tion). EXCPT is used to write several output records in one 
program cycle. If you want to put out 25 mailing labels for 
Joe Aaron, you would have to write the EXCPT operation 
25 times — one time for each record. However, instead of 
writing EXCPT 25 times, you could use a loop. One EXCPT 
code is specified. It is performed and then a backward 
branch is taken so that EXCPT will be done again. 


LOOP 


whee eee wee ome 


01 


Figure 5-49. Structure of a Loop 
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Look at Figure 5-50. The loop just described is coded here. 
But look at what will happen: An EXCPT record will be 
printed; a backward branch will cause the EXCPT to be done 
again; then another branch, and another EXCPT. When 
would execution of the statements in the loop end? As 
coded here, execution of these statements would go on in- 
definitely. 


You want to stop printing mailing labels for Joe Aaron after 
25 have been made. Therefore, you have to keep track of 
the number printed. This is done through the use of a spe- 
cial count field which is constantly updated to reflect the 
number of times looping has occurred. Figure 5-51 shows 
the way this is done. At the beginning of each cycle, 
COUNT, the field used to keep track of the number of rec- 
ords printed, must be zero. Each time a record is put out, 

1 is added to COUNT. COUNT is then compared to 25, the 
number of mailing labels desired. When COUNT equals 25, 
calculations will be complete for that program cycle, and _ 
looping will stop. When COUNT is less than 25 (indicator 
10 is on), a branch is taken back to the beginning of the cal- 
culations so that they can be done again. 


In this example, 25 mailing labels are created each cycle (for 
each record read). If a different number of records are re- 


_ quired! to be printed or punched for each cycle, you have to 


compare the COUNT field to another fie/d-which contains 
the number of records to be put out in that cycle (see Figure 
5-62). 
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Figure 5-52. Printing a Various Number of Records in Each Cycle 
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You can have as many loops in your program as you need. 
You can even have one loop within another loop (see Ee 
ure 5-53, insert A). 


Keep in mind, however, that an uncontrolled loop is an end- 
less loop. Each loop you create must be controlled so that 

it will be performed only a limited number of times. Always 
set up a condition which when satisfied will cause looping 

to stop (see Figure 5-53, insert B). 


USING SUBROUTINES IN CALCULATIONS 
A routine is something done over and over again. The cal- 


culations in your program can be called a routine because 
the operations are done again and again (on each program 


cycle). A subroutine is a routine that is part of another 
routine. That is, a subroutine is a group of operations that 
can be used by the main routine several times in the same 
program cycle. A subroutine can also be a sequence of 
Operations that is coded once and included in several a 
ferent proms: 


Subroutines can be used to: 
@ Eliminate duplicate coding by performing the same cal- 


culations several times in the same prourale cycle or in 
several different programs. 


© Reduce the storage requirements of RPG 11 programs 
(see Controlling Overlay by vgs Subroutines | in this’ 
chapter). 
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Using Subroutines to do the Same Calculations Several 
Times in One Cycle 


In many of your programs, the same operation(s) may be 
required several times in one cycle: When coding the job, 
you can specify the operations as many times as needed. 
This often involves large amounts of coding, however. If 
the same operations are to be done several times in succes- 
sion, you can often use looping to reduce the amount of 
coding. This was explained in the previous section. 


What if the same operations are not done several times in 
succession, but are performed, instead, at many different 
points in your program? Creating a loop couldn’t work in 
this case. As an example, consider the job which creates a 
weekly sales commission report. The report desired (Fig- 
ure 5-54) shows two things: 


1. Total commission earned by each salesman. 


2. Total commissions paid in each district. 


The area in which all salesmen work is divided into three 
districts: A, B, and C. Some salesmen work in only one 
district. Others may work in parts of two or more districts. 


For each salesman, the input file contains a record format- 
ted as shown in Figure 5-55. The amounts in the district 
fields show total weekly sales made by that salesman in 
each district. If the salesman did not work a district or 
made no sales in that district, the field contains a zero. 


The report must contain the commission earned in each dis- 
trict by each salesman. In addition, total commission must 

be accumulated for each salesman and for each district. The 
percentage of commission is: 


@ 3 percent of the gross sales .01 to 1000.00 dollars. 


@ Plus 2 percent of the gross sales 1000.01 to 5000.00 
dollars. 


® Plus 1 percent of the gross over 5000.00 dollars. 


COMMISSION REPORT 


Salesman Dist B 


Joe Arness 
Bob Brown 


Charles Butler 


1,998.02 * 


Figure 5-54. Sales Commission Report 
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Figure 5-56 shows the calculations needed to find the infor- 


mation required for the report. You first compare the con- | 


tents of each district field to zero to find out if the sales- 
man sold anything in that district. If it is not zero, you cal- 
culate the commission (COMM) earned. You then add com- 
mission earned to total commission for the salesman 
(MANTOT) and to total commission paid in each district 
(TOTALA, TOTALB, or TOTALC). 


The calculations needed to find commission earned are the 
same for each district (Figure 5-56, inserts A, B, C, lines 
3-16). Why code these calculations three times? Why not 
code them once and branch to them each time they are 
needed? (See Figure 5-57.) 
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Factor 2 


Using the branching you have learned about so far, the 
branching that uses GOTO and TAG, you could easily __ 
branch to the calculations needed to find commission. But ( 
since you could branch to them from three different places, 
it would be difficult to determine to which point in the 
calculations you should return. You could return to the 
point where totals are accumulated for district A, the point 
they are accumulated for district B, or the point they are _ 
accumulated for district C. Imagine the number of indica- 
tors and SETON and SETOF operations necessary to do 
this. Wouldn’t it be nice if the program would automatically 
go back to the point from which it branched? » 


RPG II can do this through the use of a subroutine. Your 
entire program is the main routine. The operations to be 
performed several times in the program cycle make up a — 
subroutine. In this case, the main program uses the sub- 
routine to find commission earned. 
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Not this: 
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calculate 
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Figure 5-57. Branching to Similar Calculations 


Specifications for Coding a Subroutine 


Subroutines are specified on the Calculation sheet after all 
detail and total operations. Every statement in the sub- 
routine must be identified as part of the subroutine by the 
letters SR in columns 7-8. (See Figure 5-58.) In addition, 
two operation codes, BEGSR and ENDSR, are needed to 
establish the beginning and end of the subroutine. 


Every subroutine used in the program must have a unique 
name. The rules for forming a subroutine name are the 
same as those for forming a field name. The name must 
appear in Factor 1 on the same line as the BEGSR opera- 
tion code. 


5-48 
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Figure 5-58. Structure of a Subroutine 


Calling the Subroutine 


When using GOTO and TAG, you use a GOTO operation 
code to branch to the next operation to be performed. 
When you do the operations in a subroutine, you do not 
branch to the subroutine; you ca// it. 


When you call a subroutine, you use the execute subroutine 
(EXSR) operation code. This operation code can be placed 
anywhere in the calculation operations. Whenever the 
EXSR operation code is encountered, all operations in the 
subroutine will be performed. After the subroutine has 
been executed, RPG II branches back to the main program 
and continues execution with the next statement after the 
EXSR statement (Figure 5-59). 


Factor 2 must contain the name of the subroutine to be . — 
executed. This same name must appear on a BEGSR 
instruction, 
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Main Program. Subroutine — - Fields Used in a Subroutine 


The same fields can be used by both the subroutine and the 
main routine. You may define the field in either routine. 

However, the name and characteristics of the field must be_ 
the same in both routines. | 


The fields you define in a subroutine should be general so 
that they apply to all situations for which a subroutine is 
used. For example, if DISTA is used as the field name ina 
subroutine to calculate district sales, you a/ways take in- _ 
formation from the DISTA field when calculating commis- 
sion. However, you want the routine also to handle infor- 
mation from the fields DISTB and DISTC. Using specific 
fields limits the correct use of a subroutine to one situation. 





Fi 5-59. EXSR (Order in Which Calculati Perf d ‘ : 2 
ee sOreiet: ony Which: Celeulasions are. Pectormad) Instead, if you use a general field name such as SALES, this 


One subroutine can be used to calculate commission in all 
three districts (Figure 5-60, insert C). However, because 
there is no input field called SALES, you should use the 
Z-ADD operation code to place information in this field 
(Figure 5-60, insert B). The information in the appropri- 
ate district field (DISTA, DISTB, or DISTC) is moved into 
the field called SALES before the subroutine is executed. 
When finding commission earned in district A, DISTA is 
moved into SALES; when finding commission earned for 
district B, DISTB is moved into SALES, etc. In this way, 
you ensure that the subroutine uses the correct information 
each time it is called, 
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Figure 5-60 (Part 2 of 4). Sales Commission Program (Using a Subroutine) 


The subroutine is called by the EXSR operation code. 


3. 


Using Subroutines in the Sales Commission Report Example 


The commission is calculated by operations specified 


in the subroutine. 


4. 


-Now that you have learned how subroutines are used, de- 


fined, and executed, see how they are used in the sales com- 


The subroutine is finished when ENDSR statement is 


executed. The instruction following EXSR is exe- 


mission report program. All specifications are shown in Figure 


5-60. 


5: 


cuted. The commission found by the subroutine is 
added to the total commission earned by the sales- 


First a record is read. Now commission earned in each dis- 


trict must be calculated. . 


man (MANTOT) and to the total commission paid in 


the district (TOTALA). 


DISTA is compared to zero to see if the salesman sold 


1. 


anything in that district. If the field is greater than 


zero, commission must be calculated. 


Now DISTB is compared to zero to see if commission 


6. 


If the field is 


If so, information from 


the field DISTB is moved to SALES, and'the sub- 


earned should be calculated. 


zero, a branch is taken to B, where another compari- 


gon is made. 


routine is called. The next steps are basically the same 


as those already described. Follow the rest of the pro- 


gram. 


Before the subroutine can be called 


, It must be sup- 


2. 


spent 


the con- 


' 


peied with the correct amount of sales. Thus 
tents of DISTA are moved into SALES. 
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| Figure 5-60 (Part 4 of 4). Sales Commission Program (Using a Subroutine) 


You may not branch to a statement outside of the 


subroutine (Figure 5-61, insert B). 


3. 


Using Valid Subroutine Operations 


Any operation code that can be used in calculations can be 


You cannot branch to a TAG within the subroutine 


4. 


used in a subroutine except BEGSR and ENDSR. This 
means that you can use all arithmetic, compare and testing, 


move look-up, EXSR, and branching operations. 


from a GOTO outside of the subroutine (Figure 5-61, 


insert C). 


You cannot have a subroutine coded within another 


5. 


There are limitations on some of the operations: 


subroutine. However, one subroutine can call another 


This means that within one subroutine 


you may have an EXSR statement (Figure 5-62). A 


subroutine. 


You may only branch to another statement in the sub- 
routine when using the GOTO statement (Figure 5-61, 


insert A). 


subroutine, however, cannot call itself and cannot call 


the subroutine which called it. 


You may branch to the ENDSR statement if you put 
a name in Factor 1 of the ENDSR statement. 


2. 
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Figure 5-62. Using EXSR Within a Subroutine 


Conditioning Subroutine Statements 


Any indicator which is valid in columns 9-17 can be used 
to condition an operation within the subroutine. That 
operation will then be performed only when the conditions 
established by the indicators are satisfied. The BEGSR and 
ENDSR operation code, however, cannot be conditioned 
by any indicators. 


The EXSR statement can also be conditioned by indicators. 
in this case, the entire subroutine will be performed only 
when conditions for the EXSR statement are met. For ex- 
ample, in Figure 5-63, insert A, the subroutine will be per- 
formed only if MR is on. 


Control level indicators cannot be used to condition state- 
ments within a subroutine since SR must appear in columns 
7-8. The indicators used on the EXSR statement determine 
whether the entire subroutine is performed at detail time 
or at total time (Figure 5-63, insert B). 


RPG If LINKAGE EDITOR 


The output of the RPG || compiler becomes input to the 
linkage editor, which builds the load (object) module for 
later execution. The module can be cataloged into the 
library, punched into cards, or written to diskette. 


The linkage editor combines the translated RPG II source 
code with the system library modules necessary to complete 
the program. The map of the linkage editor’s output is 
printed following the compiler diagnostic messages (if 
present). The map also indicates the amount of interna! 
storage used by portions of a program. 


The RPG {1 compiler used on Models 4, 6, 8, 10, or 12 
includes its own linkage editor, called the RPG II Linkage 
Editor. On Model 15, the RPG II compiler uses the overlay 
linkage editor that is part of the SCP. The following refers 
to the RPG I! Linkage Editor, although conceptually, it is 
identical to the overlay linkage editor. 
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Figure 5-63. Conditioning Calculations Within a Subroutine 


Linkage Editor Map 


Figure 5-63.1 illustrates the information available on the 
RPG I! Linkage Editor map. 


The Start Addr column gives the physical location in - 
storage of each module. Figure 5-63.1 shows the modules 
in ascending sequence by address (which may not always be 
the case). The root section indicates the beginning of the 
program just after the system supervisor (OEOO, in this 
case). The root section is 1,000 hexadecimal bytes long 
(see Code Length column); therefore, the next available 
location is 1E00. Note that the next higher address in the 
example is 1E00 for the input mainline section. 


Start Name if Code Name Title 
Addr Overlay Length 
OEOO 1000 RGROOT~ Root 


1E00 0100 RGMAIN Input Mainline 
1F00 0100 RGSUBS Record ID 

2000 0050 RGSUBS Input ctrl rtn 
2050 0010 RGSUBS Subseg 

2060 0020 $$CSIP 5444 consec input 
2080 0080 RGMAIN Input fields 

2100 0050 RGMAIN Detail calcs 

2150 0100 $$PGLC Lokup routine 
2250 ~ 0200 RGMAIN Detail output 
2450 OBO00 RGSUBS Constants 


Figure 5-63.1. kinkage Editor Map 


The Code Length column gives the storage requirements 
in hexadecimal. The Name column gives the name of 
system (and user) modules and designates the compiler- 
created segments (which begin with RG). The functions 
of modules are described, where practical, in the title 
column. 


The root section contains !/O buffers, constants, and 
variables required to run RPG II programs. Subseg is a 
section that has functions that are not easily describable 
by the compiler. For example, a calculation subroutine 
is called a subseg. 


The RGMAIN sections are the basic RPG I functions, 

such as input, detail calculations, total output, and so on. 
RGSUBS designates functions within the RGMAIN 
functions. The modules are listed in functional sequence; 
the subsections follow the main function. !n Figure 5-63.1, 
the lokup routine follows the detail calcs section because 

a table look-up was performed in detail calculations. 
Similarly, the constants section, because it follows the 
detail output section, was defined on the output 
specifications for detail (or heading) lines. 
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Simple Overlays Start Name if Code 
Addr Overlay Length 

An overlay structure begins if the load (object) module nen oe 

built by the linkage editor is larger than the available main 1£00 0100 


storage in a machine (the size is specified on the H-card or 
is assumed to be that of the machine used for compilation). 1F00 0700 
The linkage editor begins with low-usage modules such as 


execution time table dump and load routines, file open oe ae 
and close, LR calculations and output, and so on. It 1F00 giH#001 0200 
allocates an overlay fetch area large enough to hold the 2100 $H#to01 OOAO 
largest of the selected routines (or groups of routines) and 1FOO $##o002 0600 
calls for an overlay fetch routine, which will load into that 2500  $##002 0020 
overlay area the selected routines as they are needed. The 2520 $#002— 0010 


overlay fetch routine checks to see if a requested overlay is 
already in the overlay area before going to the disk library 
to load it. This action saves time by avoiding unnecessary 
loads from disk. Overlay Relative 
Name Start C/T/S 


Figure 5-63.2. Storage Map 


With overlays, the root section occupies the lowest position 


in storage as before. It is followed by the overlay fetch ae = i : 
routine. The overlay fetch area comes next, followed by $4003 00 01 0A 
the secondary root routine, or root 2. Root 2 is made up $744004 00 01 11 


of those routines that do not have to be overlaid., 
Figure 5-63.3. Library Map 
All the overlaid routines are given names jn the Name /f 
Overlay column. The names are $###nnn} where nnn is 
a three-digit overlay number. . 


Figure 5-63.2 shows a storage map of a program and 

Figure 5-63.3 shows a library map of the same program. 
Figure 5-63.4 is a diagram that illustrates the maps shown 
in Figures 5-63.1 and 5-63.2. The library map indicates the 
overlay size in the # Text Sectors column. You can see in 
Figure 5-63.3 that overlay #2 ($##002) is the largest, 
occupying seven sectors; this is equivalent to 0700 bytes in 
hexadecimal (all storage requirements will be stated in four 
hexadecimal digits). The storage map shows the overlay 
fetch area of 0700 bytes. It also indicates that overlay 

#2 contains the total calculations and is actually only 

0630 bytes long (0600 for total calcs, 0020 for constants, 
and 0010 for exception output). Therefore, overlay #2 
occupies seven sectors: six are full and the seventh has only 
0030 bytes of code in it. If the user wants to reduce the 
size of the program’s overlay area, he would first try to 
reduce the size of total calculations. 
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Overlay Fetch Routine 


Overlay 
Fetch 
Area 


Figure 5-63.4. Diagram of Linkage Editor Map and Storage Map 


The Relative Start C/T/S column gives relative library 
locations in cylinder, track, and sector for the overlays. 
This information does not pertain to this discussion. 


Special Open 


Sometimes a storage map will not list an overlay #1 but will 
have other overlays starting with $#4#002. This indicates 
that the special open has been implemented. The user 
cannot directly cause this to happen. The linkage editor 
provides this feature when it reduces a program's storage 
requirements. Special open does not affect throughput. 


When the open/close overlay is the largest one, special 
open is implemented, rather than having that code increase 
the storage required for the rest of the program. Special 
open causes some of the unoverlaid code in root 2 to 
overlay the open routine after the files have been opened; 
it overlays some of root 2 with close at end-of-job. 





Overlay Starting Addresses 


As the maps in Figure 5-63.5 show, there are two starting 
addresses for overlays. The main starting address for the 
illustration is 1FO0. The starting address for the suboverlay 
is always higher; in this case, it is 2300. 


Storage Map 


Start Name if Code Name Title 

Addr Overlay Length 

1FOO $F7002 0200 RGMAIN __ Detail calcs 

2100 $##002 0100 RGSUBS _ Transfer vector 

2200 $###002 0002 RGSUBS __ Contants 

2300 $###003 0100 $$PGRI Reset Resulting 
indr 

2400 $74#003 0100 = RGSUBS  Subseg 

2300 $##004 0300 RGSUBS Exception 

Library Map 

Overlay Relative #Text Start 

Name Start C/T/S Sectors Address 

$7001 07 1FOO 

$HH002 04 1F0O 

$##003 02° :: 2300 

$##004 03 2300 

$7005 03 ¢ 1FOO 

$7006 04 2300 

$744007 02 2300 


Figure 5-63.5. Storage and Library Maps 
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$##002 is a main overlay with suboverlays. There are two 
indications of this: first, it includes a module RGSUBS 
(which is titled transfer vector), and second, it is followed 
on the maps by overlays with higher starting addresses. 


The size of the overlay fetch area is the larger of (1) the 
largest overlay with suboverlays plus the largest suboverlay, 
or (2) the largest overlay without suboverlays. In Figure 
5-63.5, the size of the overlay fetch area is equal to the sum 
of the sizes of $4002 and $##006. This is not obvious 
from the maps, but the block diagram (Figure 5-63.6) 
drawn from the maps makes this clear. Overlay 2 is the 
largest main overlay with suboverlays, so it determines the 
starting address for all suboverlays. Overlay 6 is the largest 
suboverlay. Together, overlays 2 and 6 require 8 sectors or 
0800 bytes, which is greater than the 7 sectors (or 0700 
bytes) for overlay 1. 


If a user wants to reduce the size of the overlay fetch area, 
he could reduce the size of either $4002 or $##006. 
One sector, however, is all the user can expect to save 
because $##001 is just one sector smaller than the overlay 
fetch area. 
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Figure 5-63.6. Diagram of Storage and Library Maps 
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Fitting Available Storage 


The linkage editor removes modules from root 2, placing 
them into the overlay structure until the program fits into 
available storage (or until there are no more modules to 
overlay, which means the program is too large to fit). 
After a fit is obtained, there may be unused space in 
storage. If there is, an attempt is made to find small 
modules that can be removed from the overlay structure 
and placed back into that free space. 


This process of moving overlaid modules back into main 
storage might give you a missing overlay, that is, a 
suboverlay without a main overlay. In the storage map, 
you can sometimes notice unoverlaid modules among 

the overlays. This is a result of moving modules from main 
storage to an overlay and back again. 


The linkage editor moves code rather than allowing 
‘available storage go unused. Having code moved back to 
main storage can improve speed of execution, but is not 
under the control of the user. The linkage editor moves the 
code when it can. 


RPG 11 Logic and Function Shifting 


The basic functional areas of RPG II logic are summarized 
in the following sequence: 


1; Detail Output—Detail and heading output (except for 
overflow lines) are performed. 


2. Physical Input—Records are read from primary and 
secondary files, as necessary, and the ID indicator 
is set. 


3. Total Calculations—All calculations with L and a 
number in columns 7 and 8 are performed. This 
includes all exception output specifications if EXCPT 
is performed, or all required input specifications 
for READs or CHAINs performed, or any user 
subroutines called with EXSR. 


4. Total Output—Total output (except for overflow 
lines) is performed. You should note that total 
calculations and output are attempted on every 
cycle. 


5. Overflow Output—All output lines with overflow 
indicators conditioning them are performed. 


6. Logical Input—Data read in Step 2 is moved to the 
fields named on the input sheet, and the 
corresponding field indicators are set. 


7. Detail Calculations—All calculations without L and 
a number in columns 7 and 8 are performed. See 
Step 3 for more information. 


These functional areas can be identified by the titles of 
routines in the storage map. A user can reduce the size 
of any of these areas by one of three methods: 


@ Removing function from the program 

@® Using more efficient coding 

@ Shifting function from one general area to another 

The removal of function from a program often results in 

a second program being written to perform those functions. 
Some system designs include luxuries that are not essential 
to the job. These functions may be removed from the 
program. 

Functions that cannot be removed can often be moved to 


another area. Some total calculations can be moved easily 
to detail calculations. 
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The following multiply statement could be moved to detail 
calculations by conditioning it with the 01 indicator, just 
like the add, and deleting the L1 indicator on the MULT 
statement. The results will be identical. Similarly, some 
calculations can be moved from detail to total; however, 

a new record ID indicator will be on so the user may have 
to use an extra indicator. 


Cc 01 AMT 
CLi TOTAL 


ADD 
MULT 


TOTAL 
RATE 


TOTAL 
DISCNT 


Primary and secondary input are done at input time. 
READ and CHAIN are performed during calculations. If 
calculations are too big, a file processed with the CHAIN 
operation code might be first sorted and then matched as 
a secondary file against the primary. If input is too big, a 
secondary file could be made a demand file and processed 
with the READ operation code during calculations. 


Output, like calculations, can be shifted between detail and 
total calculations. Even overflow output can be moved 

to the following detail or total calculations by using a 
numeric indicator, which is SETON conditioned by the 
overflow indicator. EXCPT is output performed during 
calculations. Some output functions may be moved from 
output to calculations (either detail or total). 


Any calculation overlay or suboverlay that does an EXCPT 
will contain all E output specifications. If a suboverlay has 
EXCPT in it and is too large, that operation can usually be 
moved to another subroutine. !f the subroutines are large, 
they can usually be divided into several smaller subroutines. 


Calculation sections cannot be divided by the linkage editor 
to be separate overlays; subroutines can. They will become 
suboverlays to the main detail or total calculations overlay. 
If one subroutine calls another subroutine, both will appear 
in the same suboverlay. To divide them up, the first 
subroutine must return to regular calculations from which 
the second subroutine can be called. 


Using shared I/O for disk files can save a great deal of space 
in some programs. With the resulting smaller overlay 
structure, performance may be improved. Alternatively, 
larger disk file buffers and double buffering could be 
specified. These two techniques use extra storage 

(resulting in more overlays) but may still perform faster 
because of the speed improvement in disk operations they 
provide. Selection between larger disk |/O buffers or shared 
buffers must be made by trial for each program. 


Information about the overlay linkage editor can be found 


in the /BM System/3 Overlay Linkage Editor Reference 
Manual, GC21-7561. 
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SPECIAL USES OF CONTROL LEVEL INDICATORS 


At this time, you should be familiar with the normal use of 
control level indicators, L1-L9. You know that by assign- 
ing them on the Input sheet and using them on the Calcula- 
tion and Output Specifications sheets you can do total 
operations. 


In this section, you will learn to work with a special internal 
control level indicator LO. You will also learn to use L1-L9 
indicators to condition calculations and to perform group 
printing. 


Internal Control Level Indicator LO 


LO is a unique control level indicator which is always on. 
You cannot assign it to a field, as you do L1-L9, by enter- 
ing it in columns 59-60 of the Input sheet. But, you can 
use it to condition a calculation or output operation. The 
operation so conditioned will be done at total time for 
every program cycle, since LO is always on. 


The main purpose of the LO indicator is to allow you to 
specify total operations when indicators L1-L9 are not 
available or when they cannot accomplish the job. 


oa 


ee a 


Suppose you want to print the report shown in Figure 5-64, 
The report is a listing of items a company has sold in each 
of its two districts. The report includes total sales for each 
district (DISTOT) and a grand total of sales in both districts 
(GDTOT). The input records are grouped by district with 
District 1 records preceding District 2, Each record con- 
tains an item number field (ITEM), an item description 
(DESCR), and an item cost field (COST), as shown in Figure 
5-65. 


A record identification code in position 1 indicates in which 
district the item was sold. Normally, the field containing 
the record identification code could be used as a control 
field in the printing of district totals. However, each dis- 
trict has more than one record identification code. District 


343261. PORTABLE COMPRESSOR 


46F419 PORTABLE GENERATOR, 30KW 


21P006 HYDRAULIC JACK 


DISTRICT TOTAL 


34J261 PORTABLE COMPRESSOR 
16A300 PORTABLE SPRAYER 


80D610 PORTABLE GENERATOR, 50KW 


DISTRICT TOTAL 


GRAND TOTAL 


Figure 5-64. Format of District Sales Listing 


Record 
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| ITEM DESCR 
l | 


Figure 5-65. Format of Sales Record 
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1 uses either a 1 or an M as an identifier and District 2 uses 
either a 2 or an N. Since the contents of the record identifi- 
cation field can change without actually having a change in 
district, this field cannot be used as a control field. Neither, 
of course, can the ITEM, DESCR, or COST fields be used as 
control fields. 


Artificial Contro! Breaks 


When it is necessary to do total operations but no control 
fields are available to cause a control break, you can use LO 
to cause an artificial control break. Figure 5-66, insert B, 
shows the use of LO to permit total calculation operations. 


623.21 
1,459.95 
260.00 


Additional 
items 
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623.21 


930.00 
3,016.50 


i Additional 
items 
131,219.04* 


218,566.20** 
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Figure 5-63. Conditioning Calculations Within a Subroutine 


You must give priority to subroutines to determine which 
subroutines, rather than object cycle routines, should be 
stored on disk. Those subroutines used infrequently should 
be the first routines stored in the object library. Priority is 
established through the order in which the subroutines ap- 
pear at compilation time. The last subroutine in your source 
program will be the first subroutine stored in the object 
library. Consequently, you should place an infrequently 
used subroutine as the last subroutine i in your source 
program: 


Subroutine 
| 


Subroutine 
2. 


The last subroutine in your 
source program is the first - 
subroutine stored on disk. 


Subroutine 
3 
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SPECIAL USES OF CONTROL LEVEL INDICATORS 


At this time, you should be familiar with the normal use of 
control level indicators, L1-L9. You know that by assign- 

ing them on the Input sheet and using them on the Calcula- 
tion and Output-Format sheets you can do total operations. 


In this section, you will learn to work with a special internal 
contro! level indicator LO. You will also learn to use L1-L9 
indicators to condition calculations and to perform group 
printing. 


Internal Control Level Indicator LO 


LO is a unique control level indicator which is always on. 
You cannot assign it to a field, as you do L1-L9, by enter- 
ing it in columns 59-60 of the Input sheet. But, you can 
use it to condition a calculation or output operation. The 
operation so conditioned will be done at total time for 
every program cycle, since LO is always on. 


The main purpose of the LO indicator is to allow you to 


specify total operations when indicators L1-L9 are not 
available or when they cannot accomplish the job. 
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Suppose you want to print the report shown in Figure 5-64. — 


The report is a listing of items a company has sold in each 
of its two districts. The report includes total sales for each 
district (DISTOT) and a grand total of sales in both districts 
(GDTOT). The input records are grouped by district with 
District 1 records preceding District 2. Each record con- 
tains an item number field (ITEM), an item description 
(DESCR), and an item cost field (COST), as shown in Figure 
5-65. 


A record identification code in position 1 indicates in which 
district the item was sold. Normally, the field containing 
the record identification code could be used as a control 
field in the printing of district totals. However, each dis- 
trict has more than one record identification code. District — 
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Figure 5-64, Format of District Sales Listing 
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Figure 5-65. Format of Sales Record 
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1 uses either a 1 or an M as an identifier and District 2 uses 
either a 2 or an N. Since the contents of the record identifi- 
cation field can change without actually having a change in 
district, this field cannot be used as a control field. Neither, 
of course, can the ITEM, DESCR, or COST fields be used as 
control fields. 


Artificial Control Breaks 


When it is necessary to do total operations but no contro! 
fields are available to cause a control break, you can use LO | 
to cause an artificial control break. Figure 5-66, insert B, 

shows the use of LO to permit total calculation operations. 
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Figure 5-66 (Part 1 of 2). Calculations Using an Artificial Control Break (LO Indicator) 
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Figure 5-66 (Part 2 of 2). Calculations Using an Artificial Control Break (LO Indicator) 
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Assume that the following five records are read: 


‘Identifying 
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) 


Non 


The operations performed on these five records are as fol- 


lows: 
Record 


(1) 


(2) 


(3) 


(4) 


(5) 


Indicators On Operations Performed 


LO 


LO, 21 


LO, 21 


LO 


LR 


01 turns on. 

No total operations are per- 
formed because conditions 
in lines 5-6 (Calculations 
sheet) are not met. 
(Remember that operations 
conditioned by control level 
indicators in columns 7-8 are 
performed first, but are by- 
passed on the first RPG II 
cycle.) 

COST is added to DISTOT. 
21 is set on. 

ITEM, DESCR, and COST 
are printed out. 

01 is turned off. 

21 remains on. 


01 is turned on. 

No total operations are per- 
formed. 

COST is added to DISTOT. 
ITEM, DESCR, and COST 
are printed out. 

01 is turned off. 

21 remains on. 


QO2 turns on. 

DISTOT is added to GDTOT. 
(Conditions for the total 
operation in line 5 have been 
met.) 

DISTOT is printed out. 
COST is added to DISTOT. 
21 is set off. 

ITEM, DESCR, and COST 
are printed out. 

02 is turned off. 


02 is turned on. 

No total operations are per- 
formed. 

COST added to DISTOT. 
ITEM, DESCR, and COST 
are printed out. 

02 is turned off. 


DISTOT added to GDTOT 
(LR indicator is on). 
DISTOT and GDTOT printed 
out. 


Using Control Level Indicators as Calculation Conditioning 
Indicators 


Control level indicators are normally entered in columns 7-8 
of the Calculation sheet where they specify which calcula- 
tions are to be done at total time. They may, however, be 
used in columns 9-17 also where they indicate which detail 
operations are to be done on the first record of a control 
group. . 


- Control level indicators are turned on near the beginning of 


the program cycle if the contents of the control field on the — 
record just read are different from the contents of the pre- 
vious control field. Since the indicator is not turned off un- 
til the end of the cycle, it is on during total and detail time.. 
Thus, it is available to use as a conditioning indicator during 
detail time as well as total time. _ 


When an operation is not conditioned by control level indi- 
cators specified in columns 7-8 of the Calculation sheet, the. 


operation is done at detail time. If the operation is condi- 


tioned by a control level indicator specified in columns 9-17, : 
and not in 7-8 the operation is still done at detail time, but 
only when the control level indicator is on. And when is » 
the control level indicator on? Only during the processing 

of the first record in a control group as only the first record 
in a new group Causes a control break. 


Group Printing 


In group printing, data from groups of input records is 
summarized and printed as totals on a report. Sometimes,. , 
a field on each record in an input file is accumulated and 
only the final total is printed. At other times, subtotals are 
created by adding the contents of a field from a certain 
group of records and printing the result. 


Printing Only the Final Totals 


It is possible to add the contents of a field from all data 
records, and print only the total accumulated. You may 
want to do this when you are not interested in any of the 
detail information, but you do need a summation of that 
information. 


Figure 5-67 shows the coding for a program that finds the 
totals for two fields of information and prints only those 
totals. Notice, when printing only totals, the Input sheet 
need only contain those fields that will be used in the calcu- 
lations or in the printing. The Output-Format sheet shows 
only a total line (T in column 15). That line is not printed 
until the last record has been processed (LR in columns 
24-25). Then, one line is printed, containing the total 
quantity, total cost, and a constant (see insert on Output- 
Format sheet). 
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Group Printing of Subtotals 


Figure 5-68 shows group printing of subtotals. The input 
records for the program contain item, quantity, and cost 
fields; they were previously sorted by like items. 


Figure 5-69 shows the coding to produce the report. Since 
a subtotal is to be calculated for each different type of item, 
the field ITEM is designated as a control field on Input _ 
specifications. The calculations show that, as each input 
record is read, the values in the QTY and COST are | 
accumulated into subtotal fields. At each control break, 
the subtotal fields; SUBOTY and SUBCOS, are accumulated 
into final total fields. | 


The Output-Format sheet in Figure 5-69 shows eens for 
three different types of printed lines: 


@ A detail line, which is printed for each input record read. 
Note the use of a control level indicator on the ITEM 
field. This causes the field to be printed only for the 
first record of each control group (see Figure 5-68), 
making the report less cluttered and easier to read. This 
is known as group indication (see index entry). 


© A total line, conditioned by L1, which is printed only 
after each complete group of like items was read, that 
is, after each control break. 


© A final total line, conditioned by LR, which is printed 
only once, after all records were processed. 


If you want the subtotals to be the sums of only the 
quantities and cost in one section (for instance, only those 
quantities and costs under item ABCD), it is necessary to 
set those fields back to zero after they have been printed 
and added into the final totals. This process is indicated 

in column 39. The B entries indicate that the totals, SUB 
QTY and SUBCOS, are to be blanked out, or zeroed out, 
after they are printed, when the control field (ITEM) chang- 
es. They are set back to zero so that they can correctly 
accumulate the quantities and costs for the next item. 
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@ Figure 5-69 (Part 2 of 2). Group Printing 


Group Printing with Two Control Level Indicators 


Certain programs require two or more control levels. Nine _ 
levels (L1-L9) are possible. This program uses two of these, 
L1 and L2, to produce the report shown in Figure 5-70. 


Each record in the input file contains the part number of 

an item, the quantity of items sold, and a number to identi- 
fy the salesman who sold those items. The file has been 
previously arranged by salesman number. That is, all records 
for salesman number 12 are together, all records for sales- 
man number 13 are together, and so forth. Records are 

also grouped by item number within each salesman group. 


On the printed report, the salesman number is to be printed 

once; part numbers are in the next column with the sums 

of quantities for each part number in the rightmost column. 

Subtotals are printed for each salesman and a final total © 

is printed at the end of the report. __ : 
z { 

Figure 5-71 shows the coding to produce the report. Since 

the PARTNO field changes most frequently (there are 

several part numbers for each salesman) that field is the 

lowest level control field and is assigned indicator L1 on the 
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Input sheet. The next higher level control field, which does 
not change as frequently, is SLSNUM; therefore, SLSN UM. 
is assigned indicator L2. The calculation on the first line 
(01 indicator specified) occurs for every record that is read. 
QTY is added to a total, OQTYSUM. Line 2 occurs only « 
when the control field, PARTNO, changes, because L1 
(columns 7 and 8) controls this calculation. So, when L1 

is on, QTYSUM is added to another total, SUBTOT. The 
third line describes the calculation of a final total, FINOT. 
This calculation occurs when L2 is on (when the control ' 
field, SLSNUM, changes). 


When the higher level control level indicator (L2) is on, the 
lower level indicator (L1) is also on. As shown on the Out- 
put-Format sheet, when L1 is on, PARTNO and QTYSUM 
are printed (lines 03 and 04). However, the field SLSNUM 
is conditioned by L2, so it-is printed only for the first record 
of each L2 control group. When L2 is on, SUBTOT and 
the constant SUBTOTAL are printed (lines 05-07). When 
LR is on, FINTOT and the constant FINAL are printed. 
The two subtotals, QTYSUM and SUBTOT, are zeroed 
after printing by entering a B in column 39 (lines 04 and 
06). Detail lines need never be blanked after, nor does a 
final total (regulated by the LR indicator). . 
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Figure 5-70. Group Printing — Report Produced Using Two Control Level Indicators 
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Figure 5-71 (Part 2 of 2). Group Printing with Two Control Level Indicators 
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BINARY FIELD OPERATIONS (CONTROLLING 
SWITCHES) 


Note: This topic is intended for IBM System/3 Model 6, 
Model! 10, Model 12, and Model 15 programmers. 


RPG II provides certain operation codes which set and test 
individual bits in storage. These individual bits can be set 
and tested to allow you further control over processing. 
When this is done, the bits are called switches and their - 
functions are similar to that of RPG II indicators. The 
operation codes which set and test the bits are known as 
binary field operations. A binary field is a one-byte field 
containing 8 bits identified left to right by the digits 0-7. 
The bits can be set on, set off, and tested. Since each bit 
can be utilized, there are eight indicators in every byte. 


When using binary field operations, remember how data 
fields are initialized by the system: 


@ Alphameric fields are initialized to Hexadecimal ‘40’. 
@ Numeric fields are initialized to Hexadecimal ‘FO’. 
You should initialize the binary field containing the bits to 


be set and tested to binary zero (Hexadecimal ‘00’) at the 
beginning of the program. 
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BITON Operation Code 


Figure 5-72 shows a Calculation sheet containing the BITON 
operation code. This operation code causes specified bits in 


_ Factor 2 to turn on (set to 1) in the field named in the Re- 


sult Field. The field named in the Result Field must bea _ 
one:position alphameric field. Since it is one position in 
length, a 1 must be entered in column 51 of Field Length. 
One or more of the eight bits can be turned on. To turn on 
the first bit in a field, enter 0 in Factor 2. These bit num- 
bers must be enclosed by apostrophes. . 


You can condition the operation with indicators in columns 


7-17. You may also turn on a bit in an array element, but 


that array element must be one position in length. 


In Figure 5-72, bits 0, 1, and 7 are set to 1 in the binary 
field labeled CODE. 


BITOF Operation Code 


Figure 5-73 is a sample Calculation sheet containing the 
BITOF operation code. This operation code causes speci- 
fied bits identified in Factor 2 to turn off (set to 0) ina 
field named in the Result Field. In Figure 5-73, bits 0, 3, 
and 4 are turned off (set to 0) in the binary field labeled 
CODE. | 


All other specifications are the same as those specified under 
BITON Operation Code. 
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TESTB Operation Code 


Figure 5-74 is a sample Calculation sheet with the TESTB 
operation code. This operation code causes specified bits 
identified in Factor 2 to be tested for an off or on condi- 
tion. Resulting indicators in columns 54-59 are set depend- 
ing upon the conditions. At least one resulting indicator 
must be used with the TESTB operation, and as many as 
three can be named for one operation. Two indicators may 
be the same for one TESTB operation, but not three.. Re- 
sulting indicators in these columns have the following mean- 
ings: 


© Columns 54-55: An indicator in these columns is turned 
on if all the bits in Factor 2 are off (set to 0). 


@ Columns 56-57: An indicator in these columns is turned 
on if two or more bits were tested and found to be of 
mixed status, some bits on and other bits off. 


@ Columns 58-59: An indicator in these columns is turned 
on if all the bits in Factor 2 are on (set to 1). 
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Figure 5-74. The TESTB Operation Code 
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In Figure 5-74, bits 4, 5, and 6 in the binary field named 
CODE are tested. Resulting indicator 66 is turned on if | 
bits 4, 5, and 6 are off. If some are on and others off, re- 
sulting indicator 77 is turned on. If they are all on, result- 
ing indicator 88 is turned on. 

All other specifications are the same as those ae 
under B/TON Operation Code. However, you need not 
define the Result Field as one position in length, since this 
is done when the field is used in a BITON or BITOF opera- 
tion code. 
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Example 


Fields are sometimes present in customer master files to in- 
dicate particular types of customers. When such a master 
file is created, each of the conditions indicating a particular 
customer type is represented in a record by a one-position 
field. Since each position occupies one byte of storage, four 
positions indicating customer types will be stored in four 
bytes of storage. You can use binary field operations to 
convert each one-byte record position to one bit of informa- 
tion on disk. Therefore, four bytes of information can be 
reduced to four bits of information on disk. 


For example, assume you have a customer master file on 
cards. You have four columns containing the following in- 
formation: 

@ Whether the customer is a wholesaler or retailer. 

@ |f the customer is entitled to a discount. 


@ If orders should be checked by the credit department. 


@ If due to a bad payment history, the shipment should be 
sent cash on delivery. 


Now you want to place the card file on disk, and the in- 
formation from the four columns in four bits in a binary | 
field labeled CHECK. The four columns will be labeled 
WHLSE, DSCT, CREDIT, and COD respectively. The fol- 
owing operations should be performed: 


1. If WHLSE is equal to 1, ti on bit 0 in CHECK. 
2. If DSCT is equal to 1, turn on bit 1 in CHECK. 

3. If CREDIT is equal to 1, turn on bit 2 in CHECK. 
4. If COD is equal to 1, turn on bit 3 in CHECK. 
Figure 5-75 shows sanieek coding for this problem. Re- 
member that before setting up data in a binary field, the 


binary field should be set to binary zero. This can be done 
by the BITOF instruction (Line 1, Figure 5-75). 


INCREASING THE SPEED OF OPERATIONS (DUAL 
1/O AREAS) s 


During the normal RPG II cycle, a record is read, calcula- 
tions are performed, and output is produced. The cycle is 
repeated for each record. 


The speed at which the cycle is done depends upon the 
speed at which records are read and output produced. Cal-. 
culations take less time than reading, printing, writing to 
disk, or punching. The speed of doing output can be in- 
creased by using dual input/output areas. 


Dual Input Areas 


When dual input areas are used, the program cycle is 
changed. First a record is read. At the same time, calcula- 
tions are being performed on this record, another record is 
being read. Thus, the contents of two records are in the 
computer at the same time. Figure 5-76 shows how the 
records are processed when two input areas are used. 


Dual input areas can be specified for sequential disk files or 
direct disk files processed sequentially, for card files desig- 
nated as input files, or for tape input files. No stacker 
selection can be specified for card files. Dual input areas 
cannot be specified for combined or update files, table, or 
demand files. When shared input/output is specified in the 
header card, all devices which can use shared input/output 
are automatically excluded from use of dual input areas. 
(Note to Model 6 Programmers: Dual input areas can be 
used for data recorder input files. Dual input areas cannot 
oe assigned to disk, data recorder, or ledger card device files 
using a shared input/output area, specified in column 48 

of the Control sheet.) 
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Figure 5-76. Dual Input Areas 
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| Note: The shaded areas represent records being processed. 


Records A and B are 
initially read into 
storage. 


After Record A is 
processed, Record C 
is read while Record 
B is processed. 


After Record B is 


processed, Record D 
is read while Record 
C is processed. 
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Dual input areas require more computer storage space than 
one input area, because two records are in storage during 
each cycle. If you have a large program, you might not 

have enough storage space to accommodate two input areas, 
The effect of dual input areas can be determined only if you 
have knowledge of a program’s processing requirements and 
experience in RPG II programming. In some cases, you can’ 
only make a final determination by actual experimentation. 
(Note to Disk Programmers: \f your program plus two input 
areas require more space than is available, certain RPG II 
object cycle routines remain on disk during execution and - 
are called into storage as needed. If too many routines re- 
main on disk, the performance of your program may be de- 
creased by the use of dual input areas rather than increased.) 


Specifications 


One entry on the File Description sheet is required to speci- 
fy dual input areas: any digit (1-9) in column 32 assigns dual 
input areas for the specified file. Figure 5-77 shows the file 
MASTER has been assigned dual input areas. 
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File Description Specification 


Fite Type Mode of Processing 
Length of Key Field or 


File Designation 
of Record Address Field 


Record Address Type 
Filename Type of File 
File Format Organization 


or Additional Area 





Figure 5-77. Specifying a Dual Input Area 


Dua! Output Areas 


When dual output areas are used, the program cycle is 
changed. A record is written or punched out at the same 
time calculation and output operations are being done in- 
ternally to produce the next record. (Calculation opera- 
tions are not done at the same time as writing or punching 
when only one output area is used.) Figure 5-78 shows 
how output records are produced using dual output areas. 


Dual output areas, like dual input areas, require more com- 
puter storage. Consequently, the same space considerations 
that apply to dual input areas also apply to dual output 
areas. Dual output areas can be used for sequential and 
direct disk output files, Model 10 printer files (5203 printer), 
tape files, and card output files. Dual output areas cannot 
be specified for combined or update files. Also, dual out- 
put areas cannot be assigned to Model 6 data recorder, disk 
or ledger card device files and Model 10 or Model 15 disk 
files that use a shared input/output area. — 


Specifications 


One entry is required on the File Description sheet to speci- 
fy dual output areas: any digit (1-9) can be entered in col- 
umn 32 for an output file. Figure 5-79 shows the file 
PRINT has been assigned dual output areas. 


File Addition/Unordered 
Extent Exit Number of Tracks 
for DAM for Cylinder Overflow 
Symbolic Name of Number of Extents 


Label Exit 


Core Index 
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Output area 1 : Record A is in output area 1. fh 
While record A is being written | 
‘\ or punched calculations are 
performed on record B, and it 


Output area 2 is moved to output area 2. 


Output area 1 When record A is finished, record 
B is ready to be written or punched. 
|] While record B is being written or 


punched from area 2, record C is 


Output Area 2 calculated and moved into area 1. 


Output area 1 Record D is calculated and 


moved into area 2, while 
record C is being written or 


Note: the shaded blocks represent records being written, 
punched, or printed. 





Figure 5-78. Dual Output Areas 
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Figure 5-79. Specifying Dual Output Areas 
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Additional Uses of Indicators 


1. What effect do halt indicators have on System/3 operations? How can you use halt 
indicators to handle error situations? ~ . 


2. Describe a method to eliminate an output file for one program run without having to 
rewrite specifications and recompile the program. : 


3. | When conditioning a calculation specification with an indicator, what happens. when 
the indicator is on? What happens when it is off? 


4. Describe what the TESTZ operation does. 





5. 
Factor 1 Operation | Factor 2 
sire! [11 
ESNet aes sl 
Using this TESTZ specification, tell what the status of indicators 93, 94, and 95 will be 
‘ when the field TEST contains: 
a. ABC 
b. &/* 
c. JOH 
d. 789. oo 


Resulting 
Result Field 


Factor 1 Operation Factor 2 
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Using this COMP specification, tell what the status of indicators 96, 97, and 98 will 
be when the fields FIRST and SECOND contain: 


First Second 
16942 17942 
16000 15000 
19645 19645 
18921 18931 


ae of 


Controlling Operations on the Basis of the Next Record in a File 


7. 


Basically, what does the look ahead facility allow you to do? What limitations apply 
to its use? 


To the input specifications given add those which will allow you to look ahead in 
order to read the next part number (PARTNO) and next code in column 96. 
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Moving Data 
9. With MOVE, which position of Factor 2 is moved first and where is it positioned in 


10. 


12. 


the Result Field? 


What happens in a MOVE operation if Factor 2 is larger than the Result Field? 
What happens if it is smaller? 


With MOVEL, which position of Factor 2 is moved first and where is it positioned 
in the Result Field? 


What sign does a numeric Result Field have after a MOVEL operation? 


Sa 
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13. FIELD1, a 4-position positive numeric field, contains 3456; FIELD2, an 8-position 
negative numeric field, contains 87654321. What will the contents of the Result Field 
be after each of the following instructions is executed, if FIELD1 and FIELD2 contain 
the above values before each instruction is executed? 
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Branching in Calculations 

14. What is the purpose of branching? — 

15. How is branching specified in RPG 11? 

16. By using branching, how can you structure a program, which has several record 
types each of which requires different calculation operations, so that it is easy to 
write and efficient to run? 

17. What must you always include in a program that has a loop? What will happen if 
you do not include this? 

Using Subroutines in Calculations 

18. When should a subroutine be used? 

19. What are the operations used to define and execute a subroutine? What entry must 
be made in each calculation line of a subroutine that is different from all other 
calculations? 


20. What limitations in the use of GOTO and TAG apply to subroutines? 


21. Where must subroutines be coded? 
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Special Uses of Control! Level Indicators 

22. When would you use the LO indicator? 

23. How can you specify calculations to be performed only on the first card of a group? 

24. When should you specify blank after (B in column 39 of the Output-Format sheet) 
for an output field? 

Binary Field Operations 


25. What are bit switches used for? - 


- 26. Code the calculation specification to: 


a. Set on bits 4 and 7 in a field called TESTER. 

b. Set off bits 1, 2, and 3 in TESTER. 

c. Test to see whether bits 1, 2, and 3 in TESTER are all on or all off. Set on indi- 
cator 01 if they are all on and set on indicator 02 if they are all off. 


Dual Input/Output Areas 


27. For which device and file types can you specify dual input/output areas on your 
system? 


Answers To Review 5 


Halt indicators may be turned on as record identifying indicators, as a result of a 

~ test on a field, or as a result of calculations. When they are on, they cause the 
system to halt after all calculations and output operations have been performed for 
- that program cycle. . 


Because a program cycle is completed before the system halts, operations may be 
performed on erroneous data. Halt indicators, when used as conditioning indicators, 
allow you to bypass calculations and output operations which would usually be done. 
- They also allow you to print error messages and stacker select any cards with errone- 
ous information. 


Use an external indicator (U1-U8) to condition the output file and operations speci- 
fied for that file. When the indicator is on the file is used; when it is off, the file is 
not used, The file is conditioned by an external indicator specified in columns 71-72 
of the File Description sheet. The output specifications must be conditioned by that 
same external indicator entered in columns 23-31 of the Output-Format sheet. 


If the indicator is on, the step will be executed. If the indicator is off, the step will 
not be executed. 


TESTZ examines the zone portion of the leftmost character in an alphameric field. 
If that position contains & or A-1, the plus indicator will turn on. If that position 
contains -, ¢ , or J-R, the minus indicator turns on. For all other characters, the 
zero indicator turns on. m3 


9394 95 


a. on off off 
b. on off off 
c. off on off 
d. off off on 


96 97 98 . 


a. off on off 
b. on off off 
c. off. off on 
d. off on off 


Look ahead allows you to use data on the next record to be processed. Normally 
only the data on the record currently being processed is available to the RPG I! pro- 
gram. Look ahead is most often used with input files. If it is used with combined 
or update files, information in the look ahead field while the combined or update 

_ file is being processed will be from the record currently being processed, not from 
the next record in the file. , 


** must be specified in columns 19-20 to indicate that the fields listed are to be 
looked at in the next card available for processing. Look ahead fields must be given 
different field names than those used when describing the file. Any alphabetic 
characters may be used in columns 15-16. 
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9. The Rakin’: low-order position of Factor 2 is moved first, to the righthand, low- 
order position of the Result Field. 


10. If Factor 2 is larger, the number of positions moved will be equal to the size of the 
Result Field. !f Factor 2 is smaller, the whole field will be noe and the lefthand 
positions of the Result Field will be unchanged. 


11. With MOVEL, the leftmost position of aca 2 is moved first to the leftmost posi- 
tion of the Result: Field. 


12. The sign of the Result Field after a MOVEL operation is performed will be the same 
as that of the low-order character of Factor 2 unless Factor 2 is smaller than the Re- 
sult Field in which case the sign is unchanged. 


13. a. 87653456 
b. 8765 
c. 4321 
d. 34564321 


14. Branching alters the sequence in which calculations are executed. It allows you to: 
a. Skip calculation operations. . 
b. Execute operations in an order other than the normal sequential order. 
c. Perform the same calculations several times in one cycle. 


15. Branching in RPG II is specified by the operations GOTO and TAG. GOTO tells the 
computer to branch to a location indicated in Factor 2 of the instruction. The TAG 
~ statement is placed at the point in your program to which you want to branch. The 
name in Factor 1 of the TAG statement is the same as the name in Factor 2 of the 
appropriate GOTO. Every GOTO requires a TAG or the program will not know 
where to branch to. Several GOTO statements may branch to the same TAG, but the 
name on each TAG statement must be unique. 
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16. 


17. 


18. 


19. 


20. 


21. 


22. 


23. 


24. 


25. 


26. 


Condition several GOTO statements with the various record type indicators. Write 
the set of specifications for each record type separately and include them in the pro- 
gram. The set of specifications for each record type will begin with a TAG statement 
and end with a GOTO statement which branches to the end of all calculations. The 
program will test the record type and branch to the correct set of specifications. At 
the end of the set of Spectlicanlons, it will branch around all other specications to 
the end of the calculation section. 


If a program has a loop, there must be some way to stop the looping. The branch 
back instruction must be conditioned so that when certain conditions have been met, 
the statement will not be executed. If this condition is not specified or cannot be 
met, the program will go into an endless loop. 


A subroutine can be used whenever the same calculations must be executed at several 
different places in a program. 


The first line of a subroutine must have the BEGSR operation code in columns 28-32 
with the subroutine name in Factor 1. The last line in a subroutine must have 
ENDSR operation code in columns 28-32. This line can have a name in Factor 1, and 
this name can then be referenced by a GOTO statement. Every subroutine line must 
have SR in columns 7-8. 


No branches can be made from a GOTO statement within a subroutine to a TAG 


’ statement outside that subroutine. No branches can be made from outside the sub- 


routine to a TAG statement within the subroutine. 


All subroutines must appear on the Calculation sheet after all detail and total 
calculations. 


LO would be used if you need to perform some calculation steps at total calculation 
time and there is no normal control Jevel indicator (L1-L9) available. A common use 
of this is to set on the other control level indicators when control fields are not 
available. 


Detail calculations are distinguished from total calculations by the fact that columns 
7-8 of the Calculation sheet are left blank for detail calculations. Since the control 
level indicator stays on through detail calculations it can be used like any other indi- 
cator in columns 9-17 to control detail calculations. The control level ineiestor will 
be on for only the first card of a new control group. 


Blank after should be used to reset a field to zero that. is used to accumulate and 
print a total for each control group. This allows the field to start with a zero 
value for the new control group. 


Bit switches are used to code and test for specified situations... With System/3 Model 
10 Disk System and Model 6, they are stored in one-byte alphameric fields in storage 
and on disk. One example is credit information in an accounts receivable file. The 
first bit might mean a COD only; the second, payment due in 30 days; the third, _ 
credit limit $1000; etc. When these conditions are coded as bit switches they take 
up less disk space than single character codes that might be used in the same way. 


See coding sheet. 
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Model 10 Card System: 


MFCU input files (no stacker select; no table or demand files) 
MFCU output files (no stacker select) 

PRINTER output files | 

PR INTR2 output files 

TAPE input file 


TAPE output file 


Model 10 Disk System and Model 12: 


MFCU * 1442 input files (no ee select; no table or demand files) 
MFCU or 1442 output files (no seks select) 

PRINTER output files | 

PRINTR2 output files 

DISK scat files (sequential and direct only) 

DISK output files (sequential and direct only) 

TAPE input files 


TAPE output files 


Form GX21-9093 
Printed in U.S.A. 


75 76 77 78 79 80 
Program 


— _ Identification 


Comments 





7 


Model 6: 

@ DISK input files (sequential and ives only; no shared 1/O) 

© DISK output files (sequential and direct only; no shared I/O) 
© DATAQ6 input files 

Model 15: Same as Model 10 Disk System, plus: 

@ 2501 input files 

@ MFCM input files (no stacker select; no table or demand files) 


@ MFCM output files (no stacker select) 
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Chapter 6. Match Fields and Multifile Processing 


Nea 


CHAPTER 6 DESCRIBES: 
How to assign match fields to one or more files. 
Use of match fields to sequence check records in a file. 


Using matching records to control the processing of multiple input files. 


BEFORE READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
How to identify input record types on the Input sheet. 
How to use field-record relation. 
How to specify stacker selection on the MFCU. 


RPG " object program cycle. 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
Checking the sequence of records within a file using see fields. 
Using match fields with field-record relation for more than one record type in a file. 
Matching records when there is only one record type in a file. 
RPG Il laaie for processing files by matching records. 
Matching records when there are sneee than one record type ina file. 
Matching records when all of the records in one of the files have been processed. 
Using match fields and control fields in the same file. 
How to determine whether a file should be primary or secondary. 
Note: You can use the review questions contained in Review 6 at the end of this 


chapter to test your comprehension of the topics in the chapter. Answers follow 
the review questions. 
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INTRODUCTION. 


Match fields are data fields on separate records that are 
compared to establish a relationship between the records. 
Match fields have two functions, depending on whether the 
related records are the same input type file or in separate 
input type files. (An input type file can be an input, update, 
or combined file.) 


Within a file, match fields are used to check the sequence 
of records on which they appear. The sequence checking is 
accomplished by comparing match fields in one record with 
the match fields in the next record of the same file. When 
two or more input type files are used by a program, the se- 

- quence of each file can be checked just as sequence was 
checked for a single file. All files that are sequence checked 
by match fields must be in the same sequence, either as- 
cending or descending. 


In addition to sequence checking records within a file, match 
fields can also be used to establish a relationship between 
records that are in separate files. That is, match fields can 
be used to match records from two or more input type files 
.to determine which record is to be processed on the current 
cycle. If two files are used in the same job and you do not 
specify the order of processing, the primary file is complete- 
ly processed first. Only then are records from secondary 
files processed. By specifying that the order of processing 

is to be determined by comparing the contents of match 
fields, however, you can cause records from secondary files 
that are related to a record in the primary file to be proc- 
essed before the next primary record. 


’ The processing of more than one input type file, with or 
without match fields, is termed mul/tifile processing. Selec- 
tion of records from more than one file based on the con- 
tents of match fields is known as multifile processing by 
matching records. 


Multifile processing is commonly used in applications where 
data files are set up to contain only a certain type of infor- 
mation. For example, a master payroll file might contain 
data which does not change often, such as an employee’s 
pay rate. Another payroll file, which would consist of new 
records every week, might contain data such as the number 
of hours an employee worked in the week. To produce a 
paycheck or other report, information from both files | 
must be used. Furthermore, the records from the two files 
. must be processed in a particular order. Matching records 
can be used both to determine which record to process on 
each program cycle and to sequence check the records with- 
in each file. 


Note to Disk Programmers: For ease of depicting input rec- 
ords and files, card-like records are shown in illustrations 
throughout this chapter. This does not imply that the proc- 
essing must be done using card files. The files can be read 
from any System/3 device that can be used as an input de- 
vice. Also, throughout the chapter, two input-type files 

are used in examples to illustrate RPG I! logic for matching 
records. RPG II logic and the rules for record selection do 
not change when more than two files are used. See the 
RPG II reference manual for your system for examples 
using more than two files. 


CHECKING SEQUENCE OF RECORDS WITHIN A FILE 


File Containing Only One Record Type | 


As you know, an A or D entry made in column 18 of a file 
description specification indicates that the records in the 
file described are to be in sequence. If you specify that the 
file EMPLOYEE is to be in ascending (A) sequence, which 
employee records in Figure 6-1 are in the correct order? 
Actually all three arrangements show the file in ascending 
order: the first is sequenced by department number, the 


_ second by name, and the third group by employee number. 


As you can see then, before the program can check the se- 


- quence of records in a file, you must specify the field or 


fields which are to determine the order. The fields on which 
the sequence is to be checked (called match fields) are iden- 
tified on the Input sheet by coding one of the entries M1- 
M9 in columns 61-62 (see Figure 6-2). 


Records within a file may be sequenced on the basis of one 
or more data fields. Up to nine fields may be used by assign- 
ing one of the entries M1-M9 to each match field. Entering 
M1 on the same line as you describe the DEPT field (Figure 
6-2) causes the records to be sequence checked according to 
department number. Thus, this file should be in ascending 
order as shown in the first group of Figure 6-1. 


When you specify more than one match field to check se- 
quence, the program considers all the match fields to be one 
continuous field, even though the fields may not be adjacent 
in a record. For this reason, all match fields assigned to a 
particular record type are considered to have the same type 
of data (alphameric or numeric). The individual fields are 
checked in order according to the level of the match field 
entry assigned to the field. M1 is the lowest level; M9 is 
considered the most important. 
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Figure 6-1. Sequenced Files 
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Figure 6-2. Assigning a Match Field for Sequence Checking 


The input specifications shown in Figure 6-3 show that Figure 6-4 shows three records from the EMPLOYEE file. 


three fields on an EMPLOYEE record are to be used for The three match fields shown would be considered one 
sequence checking. Since all records in a particular region field. If the file is specified to be in ascending order (on 
are to be together, the REGION field is assigned the high- the File Description sheet), the records are in order since 
est (M3) match field entry and, thus, is checked first.. 03037372 is lower than 03051218, which is lower than 
DSTRCT is the next match field (M2), and DEPT is the - 05029425. However, if the file is to be in descending se- 
last (M1). quence, record 1 and record 3 must be switched. 
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Figure 6-3. Assigning More than One Match Field for Sequence Checking 
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Figure 6-4. Match Fields Checked According to Level Assigned 


Processing halts when the first record out of sequence is 
read. You can then correct the order of the records to con- 
tinue processing. Note, however, that only an error in the 
direction of the sequence is detected. When sequence check- 
ing a file with match fields, RPG !1 does not cause the proc- 
essing to stop when a duplicate match field is read. This 

can be accomplished, however, by coding the sequence check 
using calculation specifications. 
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M3 M2 M1 


——+» Record 3 —————_——_> | 05 029! 425 








————— Record 2 —————» | 03 j 051! 218 
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REGION 
DSTRCT 


DEPT 


In the last example, all records in the EMPLOYEE file were 
the same record type; that is, they contained the same type - 
of information in the same location on each record. There- 
fore, a particular match field could always be found in cer- 

_ tain positions for every record in the file. 
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the other employee records, Two different record types 
are necessary because salesmen receive a percent commis- 


File Containing More than One Record Type 


sion on sales, while other employees receive a set weekly 
salary. Although commission and salary fields appear on 


When some or all of the fields on a record are in different 


positions than the fields on other records in the same file, 


only certain records, all EMPLOYEE records contain an 


employee number, department, and district, as shown in 


you have different record types. Suppose your EMPLOYEE 
file is made up of two different record types, one type for 
salesmen and one type for all other employees. An S in 


Figure 6-5. However, these common fields appear in dif- 


ferent locations on different record types. 


position 96 identifies records of salesmen; an O identifies 
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Figure 6-5. File Containing Two Record Types 
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For this particular program, you want a list of all employ- 
ees, in ascending sequence according to district. Further- 

‘ more, the records within a district are to be in sequence 
according to department and employee numbers. To ensure 
the sequence of the file, three fields on each record must be 
checked, as shown in Figure 6-6. DISTRCT is the most im- 
portant category and, therefore, is assigned the highest 
match field entry. 
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Figure 6-6. Match Fields in Different Locations on Two Records 
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Record Type’’S” for Salesman 
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Since there are two different record types, a particular 
match field may not always be in the same record positions. 
For instance, DSTRCT is in positions 15-16 on salesmen 
records, and in positions 20-21 on records for other em- 
ployees. You must tell the program where to locate the 
match fields for each record type (Figure 6-7). Once the 
program determines the record type by checking the code 
in position 96, it then looks at the appropriate match field 
positions for that record type. 


Record Type “‘O” for Other Employee 
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Figure 6-7, Assigning Match Fields to Different Record Types 
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Fields from different record types which have been assigned 
the same match value may have the same name. As shown 
in Figure 6-7, M2 has been assigned both to the DEPT field 
on salesman records and to the DEPT field on other em- | 
ployee records. 


If match fields are assigned to more than one record type in 
a‘program, all of the records (with match fields) must be 
assigned the same number of match fields. Furthermore, all 
match fields (on different record types) which are given the 
same value (M1-M9) must be the same length. Thus, all M1 
fields must be the same length, all M2 fields must be the same 
length, and so on. This, of course, means that the total 
length of the match fields must be the same for each of the 
records. 


In this example, the EMPLOYEE file contains only two 
types of records and both are assigned match field entries. 
However, match fields need not be specified for all record 
types in a file. Record types which do not contain match 
fields are processed in the order they are read. The sequence 
check, then applies only to the record types to which 

match field entries have been assigned. 


USING MATCH FIELDS WITH FIELD-RECORD 
RELATION FOR MORE THAN ONE RECORD TYPE 
IN A FILE 


In the last example, each of the record types in the EM- 
PLOYEE file is described with a separate set of input speci- 
fications. Since all of the fields to be used for matching are 
in different columns on the different record types, the same 
match field entries are assigned once for each record type. 
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Figure 6-8. Same Match Fields for Both Record Types 
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Match Fields the Same for All Record Types 


Often, however, you may find that although there are dif- 
ferent record types in a file, many of the fields are the same 
on all record types. That is, many fields have the same _ 
name, contain the same type of data, and are always found 
in particular positions of any record type in the file. For 
example, salesmen records and other employee records 
might be organized as shown in Figure 6-8. For both rec- 
ord types, all fields are the same except the COMM and 
SALARY fields and the record identifying code in position 
96. 


When only a few fields differ, record types can be described 
on the Input sheet in an OR relationship. Instead of using 
separate sets of input specifications, common fields need 

to be described only once. As shown in Figure 6-9, entries 
under Field Record Relation (columns 63-64) can then 
identify the fields which are unique to a particular record 
type. Notice that fields which are the same for all record 
types are described first. All fields related to a particular 
record type are then described before specifying the fields 
related to one of the other record types. . 


DSTRCT, DEPT, and EMPNUM are the three match fields 
to be used in sequence checking the EMPLOYEE file. 


Since they are described only once on the Input sheet with- 

out any field record relation entries, the match field entries 

also need be assigned only once (Figure 6-9). When record | 
types are described in an OR relationship and a match field 

entry is assigned to a field without any field record relation: 
entry, the match field will be used for all record types. 
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Figure 6-9. Assigning Match Fields Once for Two Record Types 


Match Fields Differ Between Record Types 


In the last example, although some fields differed between 
record types, all the fields to be used in matching were the 
same (same name, format, and record Positions). Suppose, 
however, that one of the match fields, DEPT, is in different 
record positions for each record type. The two record types 
in the EMPLOYEE file are shown i in Figure 6-10. 


EMPNUM DEPT 
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. Figure 6-10. Match Fields Differ Between Record Types 
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According to what you have learned so far, you might as- 
sign match field entries as shown in Figure 6-11. 


However, the specifications shown in Figure 6-11 will not 
work. There is an additional rule to remember in assigning 
match field entries when field-record relation is used and 
the match fields differ between record types. . If one (or 
more) of the match fields in either file is assigned without — 
a field-record relation, the rest of the match fields must be 
assigned in the same way, without entries in columns 63-64. 
_ Of course, the specifications which assign some of these 
match fields with field-record relation are still necessary. 
Notice in Figure 6-11 that two of the match fields (M1 and 
M3) are associated with all record types (without field- — 
record relation entries). Therefore, an additional entry 
(dummy entry) should be made (see line 05 of Figure 6-12) 


to assign the M2 match field (DEPT) to all record types also. 


Actually the M2 match field isn’t the same for all record - 
types, since the location of the field varies. Therefore, how 
do you know which entries to make in the Field Location 
columns of this dummy match field entry? You know that 
any one match field is always the same length, regardless of 
record type or location in the record. In this case, DEPT is 
three positions long. Any numbers which give the correct 
length of the match field can be specified as Field Location. 


As shown in Figure 6-12, positions 12-14 are specified for 
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: (positions 12-14) on whichever record type was read. Of 


course, the M2 match field is not in positions 12-14 on 
either record type so you don’t want this incorrect data to 
be used in sequence checking. It won't be, because a// of 
the match field entries are checked before the sequence 
checking is performed. \f the record read is record type 01, 
line 07 is performed. This entry tells the program that the 
data in positions 10-12 should be used for the M2 field. On 
the other hand, if record type 02 is read, line 08 is per- 
formed and the data in positions 5-7 is used instead of that 
in positions 12-14. Actually, then, when either of the spec- 
ifications in lines 07 or O08 is performed (depending on rec- 
ord type), the data used as the match field is changed, as if 
the dummy entry had never been specified. 


Although the specifications in Figure 6-12 will cause the 
EMPLOYEE file to be sequence checked correctly, there is 
a way to reduce the number of specifications required. As 
mentioned, for a dummy entry you can specify any record — 
positions which give the correct length for the match field. 
However, if you specify the actual positions associated with 
that match field on one of the record types, there is no 
need for the specification which relates those positions to 
the match field for that record type (Figure 6-13). Thus, 
by entering 10 to 12 (line 05, Figure 6-13) as the positions 
for the M2 field, you can eliminate the match field entry 
(line 07) in which the M2 field is described for record type 
01. 
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Figure 6-13. Eliminating Specifications in Assigning Match Field Entries 
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Match Fields And Multifile Processing 


After performing the dummy entry (line 05), the program 


knows the M2 match field is to be found in positions 10-12. 


If record type 01 is read, the M2 field actually is in posi- 
tions 10-12. Thus, line 07 doesn't have to be performed, 
since it does not change anything. Of course, if record type 
02 is read, the specification in line 08 is performed. This 
says, for record type 02, use positions 5-7 for the M2 field 
instead of positions 10-12. 


The field name specified for the dummy entry can be any 
name, since field names are ignored in selecting match 
fields. In this case, DEPT was specified since it happens 
that the M2 fields on both record types have the same 
name. If the names to be used differ, it is still a good prac- 
tice to use a name given to the match field on one of the 
record types. 


MATCHING RECORDS: ONE RECORD TYPE IN EACH 
FILE 


One of the most common forms of multifile processing in- 
volves using one file to obtain data from another file. Fig- 
ure 6-14 shows a weekly sales report to be printed which is 
used to determine which items are selling best at which 
location. A SALES file contains records of individual items 
sold, giving the quantity and location. The description of 
each item, however, must be obtained from an ITEM mas- 
ter file. The ITEM master file consists of one ITEM record 
for each item in stock. 
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For this program, let’s assume that each file contains only 

one record type. All | TEM records are in one format and are 
identified by the character | in position 1. All records in e 
the SALES file are identified by an S in position 1 and are 

also in one format (certain type of information in same 

location on every record). The SALES records for a partic- 

ular item can be associated with the related ITEM master 

record by a common match field containing the item num- 

ber (see Figure 6-14). 


Processing Order: More Than One Matching Record in a 
Secondary File , 


In the ITEM master file, there is only one-record for each 
item, but in a program run there may be several SALES rec- 
ords for that particular item. Let us suppose there is always 
at least one SALES record for each ITEM record. There- 
fore, there should be no records in either file which do not 
have a matching record in the other file. Both files are speci- 
fied with match fields in ascending sequence. 


To produce the report in Figure 6-14, in what order should 
records from the two files be processed? First an ITEM 

master record should be processed; that is, the item number 
and description printed. Then, all the SALES records which 
are for the same item (match fields the same) should be 
processed. The quantity and location of each sale should 

be printed under description. Thus, after every ITEM rec- f 
ord processed, one or more SALES records must be proc- i 
essed before the next record from the ITEM master file is 
processed. . 


How does RPG II know when to stop printing SALES rec- 
ords and to process the next ITEM? As we said, the SALES 
records for a particular item are read one at a time and 


' printed. When the match field on a SALES record is for a 


different item, that SALES record is not processed immedi- 
ately. Instead, the next 1TEM master record is processed to 
print the description for the new item. Then the SALES 
records for that item are printed. As you can see, to deter- 
mine the correct order of processing, both files must be in 
the same sequence according to the match field; in this case, 
in ascending sequence by item number. 


a 


SALES File 






ITEM File 


DESCRP 






~ PRIMARY FILE SECONDARY FILE 


Match Field Containing 
{tem Number 
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ITEM DESCRIPTION QUANTITY LOCATION 
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Data From Data From 
ITEM Records SALES Records 


Figure 6-14. Matching SALES Records with Related ITEM Records to Produce a Printed Report 
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How RPG I! Logic Determines From Which File to Process 
a Record 


Using the same example, let’s see how the RPG I logic de- 
termines from which file a record is to be processed. The 

’ [TEM master records are the primary file and the SALES 
records are the secondary file. When two input files are 
used in a program, the program cycle is slightly different for 
the first record read. You can follow the logic flow shown in 
Figure 6-15 as we discuss the first program cycle and sub- 
sequent cycles for this job. Pay special attention to when 
the record identifying indicator is on, identifying the rec- 
ord to be processed, and when the MR indicator is turned 
on and off. 


At the beginning of the first program cycle (Figure 6-15, 
part A), a record is read from each file. The first step is to 
determine which record to process. The program deter- 
mines if match fields are specified for both record types. 
In this case, both the ITEM record and the SALES record 
contain an M1 field. The match fields from each file are 
then compared to see which is lower in sequence. (If the 
file had been in descending sequence, the program would 
check for the highest match field.) In this case, neither 
field is lower as the match fields on the primary and sec- 
ondary records are both 101. When match fields from the 
two files are the same, the record from the primary file is 
always selected for processing. 


Now the appropriate record identifying indicator is turned 
on to identify the type of record selected for processing. 
Thus, 01 would be turned on for the ITEM record from the 
primary file. 


Once a record is selected for processing and the record 
identifying indicator is turned on, the program determines 
whether the MR indicator should be on during processing 
of the record. Since the match fields are equal (both 101), 
a matching record condition exists. The MR indicator is 
not turned on yet, however, because the selected record is 
not ready to be processed yet. 


First, the program checks to see if any total operations are 
to be performed for previously processed records. Total 
calculations and total output are performed only if control 
fields change or if the last record in the file has already been 
processed (LR on). Since there are no control fields in 
either file, control level indicators will never be turned on 


during this program. Furthermore, this is not the last record. 


Neither condition has occurred; therefore, total-time opera- 
tions are bypassed. 
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At this point, the MR indicator is turned on to indicate that 

the matching record conditon exists. Now the program is 

ready to perform the detail operations for the record which 

was selected for processing. Thus, the item number and = 
description from the primary file record are printed. The 
program knows which operations are to be performed be- 

cause the operations are either conditioned to be performed 
only when record identifying indicator 01*and the MR in- 
dicator are on or they are not conditioned by indicators. 


Once the processing of this record is completed, the record 
identifying indicator is turned off (01 off). This completes 
the first program cycle; that is, one record has been proc- 
essed. 


For the processing of all subsequent records, look at the 
program cycle in Figure 6-15, part B. The entire cycle will 
be repeated for each record processed. 


At the beginning of the first cycle, a record was read from 
both the primary file and the secondary file. However, 
since only one record is selected for processing at a time, 
one record (in this case, a SALES record) still remains in 
the input read area. Therefore, a record from only one file 
is read at the beginning of the second cycle and for all fol- 
lowing program cycles. The record read will be from the 
same file as the last record processed. Thus, for the second 
cycle, the second record from the [TEM file would be read 
into the primary file read area. : ( 


y= 


Now that a record from each file is in the read area again, 
the second record can be selected for processing. Once 
again the first step in the logic is to determine if match 
fields are specified for the records from both files. {n this 
program, there is only one record type per file and both are 
assigned match fields. Therefore, the answer to this ques- 
tion is yes for every program cycle of this program. 


The match fields from both records are then compared, In 
this case, the secondary file SALES record is for the first 
item number (101). Since the ITEM record for the first 
item (101) has already been processed, the primary file rec- 
ord in the read area is for the second item number (117). 
The match field on the SALES record is lower in sequence 
than the match field on the ITEM record; therefore, the 
SALES record is selected to be processed. Once again, a 
record identifying indicator (02 for a SALES record) is 
turned on to identify the type of record selected. 


At this point, the MR indicator is still on because the pre- 

vious comparison (item 101) did give a match. The setting’ 

of MR has nothing to do with the record which was just 
selected for processing. The indicator will not be set to re- 

flect the current condition until just before the record 

selected for processing (SALES record for item 101) is \ 
processed. 
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Figure 6-15 (Part 1 of 2). Logic of Matching Records 
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Figure 6-15 (Part 2 of 2). Logic of Matching Records 
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NO? 


~~, 


Since the next record to be processed has been selected, the 
RPG I! program now determines how the MR indicator is 
to be set for processing this card. Is there a matching rec- 
ord condition? You are probably thinking that there is not, 
because the match fields are not the same (secondary file, 
101; primary file, 117). However, when the match fields 
are not equal and a secondary file record has been selected, 
the match field on the secondary file record (SALES) is then 
compared with the match field of the last primary file rec- 
ord processed. The last !TEM record processed has a match 
field of 101, the same as the match field of the SALES rec- 
ord to be processed. Therefore, there is another matching 
record condition. 


The MR indicator is not set again and the record selected 
(SALES 101) is not processed (detail operations not per- 
formed) until after any total operations to be done for pre- 
vious records are completed. Since there are no control 
fields and this is not the last record in the file, total opera- 
tions can be skipped in this program cycle. 


At this point, immediately before processing the selected 
record, the MR indicator is set. Although MR is already on 
for the previous record processed, it is set on again for the 
processing of this record (SALES record for item 101). All 
detail operations conditioned for record type 02 (or for both 
02 and MR indicators on) are then performed. Thus, the 
quantity and location fields on the SALES record are printed. 


After printing the SALES record, processing for this record 
is complete and record identifying indicator 02 is turned off. 
In the next program cycle, another SALES record is read 
from the secondary file.to replace the SALES record just 
processed. 


For the rest of the SALES records related to the first item 
number (101), the comparison of match fields would indi- 
cate that the secondary file records are lower in sequence 
than the item number (117) on the ITEM record of the pri- 
mary file. Thus, all sales records for item 101 are processed. 
Furthermore, the MR indicator will be on during processing 
of all the records, since the match fields (101) will always 
be the same as the match field on the last primary record 
processed. 


At the beginning of the next program cycle, a SALES rec- 
ord for the next item number (117) would be read. On 
comparing the SALES record match field with the match 
field on the ITEM record in the read area, there is a match 
again. The ITEM for item 117 would then be processed be- 
fore the SALES records for that same item. 


Specifications for a Matching Records Program 
Figure 6-16 shows the three specification sheets — File De- 


scription, Input, and Output — to be used for this program. 
Since the data from the two input files is only to be printed, 


calculation specifications are not necessary. 


The File Description sheet defines the two input files to be 
used in matching, as well as the printer file, on which the 
report is to be printed. Notice that the two input files must 
both be specified as being in the same sequence (A in col- 
umn 18). The P and S entries in column 16 indicate to the 
system whether an input type file is to be considered as a 
primary or secondary file. 


File Description Specification 


File Type Mode of Processing 
Length of Key Field or 
of Record Address Field 
Record Address Type 
Type of File 
Organization 
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End of File 
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Extent Exit 
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File description specifications also associate each input file 
with a particular device. On the MFCU, the primary file is 
usually entered through the primary hopper (device entry 
MFCU1); the secondary file is usually read from the sec- 
ondary hopper (device entry MFCU2). However, in multi- 
file processing using the MFCU, either file may be associ- 
ated with either of the two hoppers. 


The contents of the two input files are described on the 
Input sheet, with a separate set of specifications for each 


file. Entries in columns 19-27 identify the two record types. 


Record identifying indicator 01 will turn on if an ITEM rec- 
ord is selected for processing; indicator 02 will turn on if a 
SALES record is selected. The single match field in each 
file is specified by assigning the M1 entry in columns 61-62, 
as you learned previously. 


Lines 01-04 of the Output sheet specify that headings are 
to be printed at the top of every page of the report. 


As you recall in the discussion of matching record logic, the 
01 record identifying indicator is on whenever an ITEM rec- 
ord is being processed. Furthermore, 1TEM records are 
processed only if a matching record condition exists (MR 
on). Therefore, conditioning the printing of the item num- 
ber and description by MR and 01 ensures that the informa- 
tion is coming from the ITEM record. 


The quantity and location are to be printed only when a 
SALES record is being processed. Because the MR indica- 
tor is on during the processing of both !TEM records and 
SALES records, it isn’t sufficient to condition this output 
line only on the basis of MR. Therefore, the printing of 
quantity and location is conditioned by both the MR in- - 
dicator and the 02 record identifying indicator. 


In this case, calculation specifications are not required. 
However, if calculations are required and are to be per- | 
formed only if a matching (or not matching) record con- 
dition exists, calculations must also be conditioned by the 
MR (or NMR) indicator. 
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Processing Order: More Than One Matching Record in the 
Primary File 


For the example just presented, there was more than one 
record in the secondary file with the same match field. 
That is, a single ITEM record was related to a number of 
SALES records. In such a case, the order of processing was 
the first primary file record, followed by its related sec- 
ondary file records, then the next primary file record, fol- 
lowed by its related secondary file records, and so on. 


Let’s take a look at another set of files, in which each rec- 
ord has a matching record in the other file. Figure 6-17, 
part A, shows that there may be more than one primary file 
record which matches the same secondary records. In what 
order do you think these records would be processed? The 
first primary file record processed would not necessarily be 
followed by its related secondary file records. Instead, all 
primary file records with the same match field AA would 
be processed; then all secondary file records for AA (see 
Figure 6-17, part B). 


Actually, the RPG II logic used to determine the order in 
which such files are processed is the same as that discussed 
previously. Remember that whenever the match fields on 
~ the two records in the read area are the same, the primary 
file record is always selected for processing. Thus, during 
the first program cycle, the first primary file record (AA) 
is compared to the first secondary file record (AA). The 
match fields are the same, so the first primary file record is 
processed. Then the second primary file record (again AA) 
is read and compared to the first secondary file record (AA), 
still in the read area. Since there is a match again, this sec- 
ond primary file record is processed. 


For both of the last two examples presented, every record 
in the secondary file had at least one or more related rec- 
ords in the primary file. Since a matching record condition 
always exists, the MR indicator was on during the process- 
ing of every record in both files. 
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Matching Records: Records Which Have No Match in the 


Other File 


In the multifile programs presented, there was at least one 
SALES record for every 1TEM master record. Therefore, all 
records had a related record in the other file. Of course, in 
multifile processing, it is possible to have primary file rec- 
ords with no related records in the secondary file, as well as 
secondary file records with no related primary file records. 
In either case, the record with no related record in the other 
file is called an unmatched record. For instance, if only 
certain items are sold, there would be an ITEM master rec- 
ord for every item and SALES records for only some of 
those items. The ITEM records for which no sales were 
made would be unmatched records. 


Unmatched records can be in either or both files, but they 
are usually found in the primary file. In this example, it is 
quite probable that for any one item, no sales have taken 
place. However, it is not as likely that sales have occurred 
for an item for which there is no record in the ITEM master 
file. 


More than one 
primary file 
record with 
same match field 





Primary File |. Secondary File 


(A) FILES BEFORE PROCESSING 






Primary records with same match fields 
processed before the secondary records 
with same match field 


ORDER OF PROCESSING THE FILES 


Figure 6-17. More than One Primary File Record with Same Match Field 
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Processing Order: Unmatched Records 


Let’s assume that the two files for this program consisted of © 
the records shown in Figure 6-18, part A, with the primary 
file containing two unmatched records. The RPG 11 logic re- 
lated to matching records would determine the order in 
which to process the records (Figure 6-18, part B). As ex- 
plained earlier, first the TEM master record for item 101 is - 
processed, followed by all SALES records for item 101. Re- 
member, if a record is selected’ for processing during a pro- 
gram cycle, the next record from that same file is read at 

the beginning of the next cycle. Therefore, when the first 
SALES record for item 117 is read, another matching rec- - 
ord condition exists. Thus, the primary file record (ITEM 
record for item 117) is processed first. The next primary 
file record for item 124 is then read to replace the ITEM 
record processed. Since SALES records with match fields 

of 117 are lower in sequence than 124, the two SALES 
records for item 117 are processed. Furthermore, although 
the match fields (117) on the SALES records are not the same 
as that of the ITEM record in the read area (124), they are 
the same as the match field of the last 1TEM record proc- 
essed. Therefore, the MR indicator is on when each SALES 
record for 117 is processed. 


When the next SALES record (item 239) is read, there still 
isn’t a match with the ITEM record for 124. The match 
field on the ITEM record is lower than that on the SALES 
record; therefore, the primary file record for item 124, an 
unmatched record, is processed first (Figure 6-18, part B). 
Since the files are in ascending sequence, this means that 
there is no record in the secondary file with a match field — 
of 124. Therefore, MR will be turned off just before the 
ITEM record for 124 is processed. 
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This program cycle shows that even if there is no matching 
record condition, the primary file may be selected for proc- 
essing. This is because RPG 11 logic looks for the record 
with the lowest match field, regardless of whether the 
record is from the primary file or the secondary file. | 


Now the next primary file 1TEM record (239) is read. Since 
it matches the SALES record in the read area, the primary 
file record is automatically selected for processing. Although 
a matching record condition exists for the 1TEM record 
selected, at this point the MR indicator is still off because of 
the last record processed (unmatched ITEM record for 124). 
The status of MR is not changed until right before detail 
operations for the selected record are performed. 


Following the ITEM record for 239, the SALES record for 
item 239 is processed. Then, as before, the unmatched 
ITEM record for item 286 is processed, since it is lower in 
sequence than item 321 on the next SALES record. To 
complete the processing, the primary file ITEM record for 
item 321 is processed, followed by the two sales records for 
item 321. oy ae 


In summary, then, RPG I} sets the MR indicator to off im- 
mediately before processing any unmatched records. MR is 
turned on before processing a record that has a matching 
record in the other file. After a record has been processed, 
the indicator remains as it was until it is set again immedi- 


.. ately before the next record is processed. 


Regardless of the records in a file, there is an easy way to 
determine if a matching record condition exists and if the 


MR indicator will be turned on: 


1: When a primary file record is selected for processing, 
MR will be turned on if there is a secondary file rec- 
ord in the read area with the same match field. 


2. | When a secondary file record is selected for process- 
ing, MR will be turned on if the last primary file rec- 
ord processed had the same match field. 
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Figure 6-18. Processing Files with Unmatched Records 
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| Stacker Selection of Unmatched Card Records 


When records from two files are assigned match fields, a 
record from one file may be processed, then a record from 
the other file, and then a record from the first file again. 
However, regardless of the order in which the records are 
processed, all cards which enter through the primary hop- - 
per of the MFCU or MFCM are automatically stacked in 
stacker 1. All cards entering through the secondary hopper 
end up in stacker 4 (stacker 5 on the MFCM Model A1). 


If there are unmatched records in either file, you can sep- 
arate such cards from the others in that file by stacker 
selecting the unmatched cards into a different stacker. As 
you learned in the chapter Card Output Operations, cards 
from an input file can be selected into a different stacker 
by entering the number of the stacker on the Input sheet. 
However, this can be done only when input cards are to be 
stacker selected on the basis of record type. 


Stacker selection of a card because it has no matching rec- 
ord in the related file must be specified in column 16 of the 
Output sheet (Figure 6-19, part A). However, an input file 
cannot be‘specified on the Output sheet. Therefore, the 
input file containing the card to be stacker selected (the 
card with no related record) must be defined as a combined 
file on the File Description sheet (Figure 6-19, part B). The 
combined file name can then be used on the Output sheet 
for stacker selection. 


Notice on the Output sheet that stacker selection is speci- 
fied for the combined file ITEM (line 11), since only the 
ITEM file contains unmatched records. The filename indi- 
cates from which file the cards will be output. Since a 
matching record condition cannot possibly exist for any un- 
matched records, MR must be off. Therefore, the stacker 
selection of records is conditioned by NMR (off). 
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Any record, conditioned for stacker selection by the MR 
indicator, should be specified as a detail-time record (see _ 
Figure 6-19, part A, column 15). Otherwise, the next rec- rs 
ord to be processed would be stacker selected instead of the | 
record you want. This is because the detail-time processing : 
of a card is done within one program cycle and the proc- 
essed record automatically passes into the normal output 
stacker, if not stacker selected. The total-time operations 
for that same record are not performed until the next pro- | 
gram cycle, after another record has been selected for proc-: 
essing. During total-time operations, although the status of, 
the MR indicator is-still set for the previously processed rec- 
ord, the only record’available to be stacker selected is the : 
card just selected for processing. . 


Whenever you wish to have a certain type of output based 
on a matching or not matching record condition, it can be 
important that a record identifying indicator be used with 
MR or NMR to condition the output. The record identify- 
ing indicator determines from which record type the infor- 
mation will be punched, stacker selected, or printed. For. 
the printer output file, output can come from either the 
SALES file or the ITEM file (Figure 6-19, part A). There- 
fore, record identifying indicator 01 or 02 is specified to 
indicate which record type is to be printed (lines 05 and 
08). Record identifying indicator 01 is entered on line 11 
in addition to NMR so that stacker selection will occur for 
the ITEM file only when an ITEM record has been processed. 
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Figure 6-19. Stacker Selection of Unmatched Records 
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Match Fields And Multifile Processing 


MATCHING RECORDS: MORE THAN ONE RECORD 
TYPE INA FILE 


Match Fields in Different Locations in the Same File . 


Let’s consider again the specifications necessary in assigning 
match fields for the weekly sales report. This time, however, 
suppose the SALES file used in producing the report con- 
tains two record types, charge records and cash records (see 
Figure 6-20). Both record types contain the item number, 
quantity, and location. In addition, charge records contain 
an account number, which cash records do not have. The 
cash sales records are identified by a C and an S in positions 
1 and 2. Charge sales records contain an S in position 2, but 
no C in position 1. Furthermore, the match fields are in dif- 
ferent locations on the two types of SALES records. 


. Recall the discussion of assigning the match fields for se- 
quence checking within a file (see Checking Sequence of 
Records Within a File). When match fields are used in more 
than one record type in a file, the match field entries must 


Match field in different 
location on different 
record types 






0165 CASH 


RECORD 






DESCRP PRICE 


Match field in same location 
on every record 


ITEM File 


_ (Only One Record Type) 


Figure 6-20. More than One Record Type in File Used for Matching 
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CHARGE 
RECORD 


either be specified one for each record type or in a field- | 
record relation. The way they are coded depends on whether 
the match fields are found in different locations oneach . ~ 
record type. If match fieids are in different record locations, \ 
they may be coded either way. However, the ease of coding 
separate specifications for each record type may be more 
important to you than the specifications and storage often - 
saved by using field-record relation. 


In assigning entries for match fields which are to be used 
for matching records from two files, the same considera- .. 
tions must be made. The only difference is that, for match- 
ing records, you are concerned with two files, rather than 
one. You know that the match field entries on the Input 
sheet must be assigned separately for each file. Then, if one 
of the files has more than one record type containing the 
match fields, the record types in that file can be described 
separately or with field-record relation. If you use field- 
record relation, just be sure a particular match field field 
entry applies to all of the appropriate record types within 
the file. 








QTY LOCATN 


SALES File 


(Two Record Types) 


As shown in Figure 6-21, first the ITEM file is described as 
it was before (see Figure 6-16, part B). The M1 entry is as- 
‘signed only once since there is only one record type in this 
file. The two record types in the SALES file have been de- 
‘scribed in an OR relationship, because most of the fields 

are in the same location on both types of SALES record. 
Note that all: fields which are the same for both record types 
of the SALES file are specified first with no field-record re- 
lation entry. Then all the fields associated with the first type 
of SALES record only (02 for charge records) are specified, 
followed by those for the next record type (03 for cash rec- 
ords). The M1 entry must be assigned twice for the SALES 
file since the match field ITNUM is in different locations on 
the two record types. 


For all records of the same record type, the match fields (as 
well as all other fields) must necessarily be in the same loca- 
tion for every record of that type. However, match fields 
may be in different locations within the same file, providing 
there is more than one record type. 


Although there is more than one record type in the SALES 
file, the order in which the records are selected for process- 
ing would be the same as explained previously for only one 
record type in each file. Before a comparison of match 
fields can be made between files, RPG II must first deter- 
mine what type of record was read so it knows where the 
match field is located on that record. 
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INPUT SPECI FICATIONS 


eo 


There are some important restrictions on the use of match 
fields for matching records between files. All records for 
which match fields are specified must contain the same 
number of match fields. This applies to both files, regard- 

less of how many record types are in either file. In the sales 
report program, only one match field (item number) was used. 
However, just as for sequence checking, up to nine match 
fields may be used to match records between files. — 


In assigning match fields to records, remember that for 
matching purposes, RPG II considers all match fields of the 
same value (M1-M9) to be in the same format, numeric or 
alphameric. Thus, if any of the match fields are defined as" 
being numeric, RPG II looks at only the digit portion of all 
the other match fields with the same M1-M9 value, even _ 
though some may be alphameric fields. 


If more than one match field is assigned, all the match fields 
in a record from one file must be equal to all the match 

fields in the record from the other file before a matching 
record condition exists. For example, assume that M1, M2, 
and M3 are match fields assigned to records in two files. In 
comparing records from each file, if the M1 and M2 fields — 
are the same, but the M3 fields differ, the records do not 
match. If the files were specified to be in ascending sequence, 
the record with the lower value match field (M3, M2, M1 
combined) would be selected for processing. 
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Figure 6-22. Files Containing Records Without Match Fields 
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Processing Records Which Do Not Have Match Fields 


Up to now, all records in a file have been assigned match 

fields to be used in matching records from ‘one file with 

those in the other file. Some files, however, may contain 

some records which are not to be matched; thus, such rec- 
ord types would not contain match fields. 


As you recall, the ITEM file was organized in ascending se- 
quence according to item number. !tem numbers are as- 
signed such that items can be grouped according to a gen-- 
eral category. All items assigned numbers from 100-199 
are automotive supplies, those from 200-299 are lawn and 
garden equipment, 300-399 are small household appliances, 
and so on. In addition to the ITEM records for each item, 
then, the [TEM master file contains a record preceding each 
group, identifying the general category to which the items 
belong (Figure 6-22). These category records are distin- 
guished by an * in position 1. 


The SALES file also contains a record type which does not 
have a match field. In addition to the two types of sales 
records, one for cash sales and one for charge sales, there is 
a DATE record at the beginning of the SALES file, identi- 
fied by 5 in position 96 (see Figure 6-22). | 
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a 
D Figure 6-23. Describing Records With and Without Match Fields Assigned 


The two record types in the ITEM master file and the three 
record types in the SALES file would be described as shown 
in Figure 6-23. On the basis of the record identifying codes, 
one of the record identifying indicators which are assigned 
to the record types (positions 19-20) will turn on to indicate 
which record type was read. 


Notice that the input specifications (Figure 6-23) assign a 


match field to only some of the record types present in the 
two files. The category records from the ITEM file and the 
date record from the SALES file are not to be matched 
with records from the other file. | 


Since match fields are used to determine the order in which 
records are processed, when will the category and date rec- 
ords be processed? Records for which no match fields are 
specified are processed immediately as they are read. To 
understand the order of processing and when the MR indi- 
cator is on, then, let's discuss how RPG I! logic operates 
during the program cycles for this program. 


Gx21.9004 U/M 050° 
+ Printed in, U. 


75 76 77 78 79 80 


Identification 


‘Field | 
Indicators 


Field Name 


Decimal Positions 
Control Level (L1-L9) 
Matching Fields or 
Chaining Fields 


STO gece 
“Et HOU ry) MIM Item records 


with match fields. 
ore rt ues 
gory pecerds: 
“6 | 25 eATeRY (tT 
Th The 
ae aa 
sales records 


with match 
fields. 


Match Fields And Multifile Processing 6-29. 


At the beginning of the first program cycle, the first record 
is read from each file. RPG !! then decides if match fields 
are specified for both records. As mentioned, a record for 
which no match fields are assigned is automatically selected 
for processing before the record in the other file. 


In this case, neither record in the read area has match fields. 
Therefore, which should be processed? Without match 
fields, the two records cannot be compared ‘to see which is 
lower in sequence. When both records do not have match 
fields, the record from the primary file has priority and, 
thus, is selected for processing. 


Since match fields are not assigned to this record type; there 
can be no matching record in the other file. Therefore, im- 

mediately before a record without match fields is processed, 

the MR indicator is turned off. 


For the next program cycle, the ITEM record for item 101 

is read to replace the category record processed. The date 
record from the secondary file is still in the read area. Since 
the secondary file record has no match fields, no comparison 
is made, and the date record is automatically processed. 
Once again, the MR indicator is turned off right before proc- 
essing a record without match fields. 


The remaining records would be processed in the order 
shown in Figure 6-24. When records ‘with match fields are 
in the read area, the record with the lowest match field is 
selected for processing. If both match fields are the same, 
the record from the primary file is always selected. Of 
course, if one of the records has no match field, it is proc- 
essed immediately after the record it follows, regardless of 
which file it is in. As shown in Figure 6-24, there are match- 
ing SALES file records for the ITEM file record with a 
match field value of 286. Since a record without match 
fields (the category record for SMALL APPLIANCES) fol- 
lows this ITEM record in the primary file, the record with- 
out match fields is processed before the SALES records 
which match ITEM record 286. You should be aware that 
this processing order may be undesirable in your program, 
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. _ time operations to be performed, and then the program 


MATCHING RECORDS: WHEN ALL RECORDS IN ONE 
FILE HAVE BEEN PROCESSED 


When you are using two or more input-type data files in a 
program, end of file is always reached in one file before all 
the cards in the other file have been processed. This is be- 
cause the matching record function can only select one card 
at a time for processing. Furthermore, each file often con- 
tains a different number of records. 


Usually, in multifile processing, you want the program to 
continue until all records from all files have been processed. 
RPG II logic will do this. The last record indicator (LR) is 


‘not turned on until the last record in the last file is read. 


-Let’s go over the last few program cycles in the example 


last presented. At a particular point in the program, there 
will be two records left in the primary file (item 321 anda /* 
record) and three records in the secondary file which have. 
not been processed (two for item 321 and a /* record). 


At the beginning of a program cycle, the ITEM record for" 
321 and the first SALES record for item 321 would be in- 
the read area. Since both match fields are the same, the — 
primary file record i is processed, with the MR indicator - 
turned on before processing. 


The next primary file record, an end of file (/*) record, is ' 


then read. Ina single file program, reading a /* record tells ~ 


_ the program there are no more data records to process. The \. 


last record (LR) indicator is then turned on causing total 


ends. 
In multifile processing, however, reading a /* record from 
one file does not necessarily mean that all records from all 
files have been processed. Thus, the program must deter- 
mine if end of file has previously been reached i in the other 
file(s). In this case, the SALES file still contains three un- 
processed records. Therefore, reading the /* record from 
the primary file merely indicates that there are no more . 
records from that file to process. The remaining data rec- 
ords in the SALES file are ‘processed, one at a time, in the 
order in which they are read. 64 


When the end of file record from the secondary file is read, 
the program determines if end of file has been reached in 
the other file. Since it has, the LR indicator is then turned 

. In this program, there are not total calculations. or. total 
sutuuk to be Perrorrricds thus, the program is ended. 
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Figure 6-24. Processing Order of Records with No Match Fields 
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In other multifile programs, you may want the program ended 
when. a certain file has been completely processed, although 
there are records left in another file. As you know, by enter- 
ing an E in column 17 of the File Description sheet you can 
specify which file is to end the program, For example, say 
the ITEM and. SALES files contain the records shown in. 


Figure 6- 25. Since both files are in ascending sequence, once . 


all SALES records have been processed, there wouldn't be 
much point in processing the remaining ITEM master rec- 
ords for which no sales were made. Thus, an E (end of file) 
entry could be specified for the SALES file. 


You should be aware, however, that in a matching records 
program, specifying the end of file entry for a particular file 
will not always cause processing to end immediately when the ~ 
last record of that file is processed. If the file which has not 
been completely processed contains records which match 

the last record processed from the completed file, the match- 
ing records will be processed before the program is ended. 


Furthermore, processing will continue for any records with- 


out match fields, until the next record with a match field is: 
read, 
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Figure 6-25. Specifying When Processing is to Stop in a Matching Records Program 
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Seca 


Assume the secondary SALES file contains the records 
shown in Figure 6-26. Following each group of sales rec- 
ords for a particular item is a record which gives the total 
sales for that item. The total records do not have match 
fields and thus are selected for processing as soon as they 
are read. 


An end of file entry is assigned to the primary ITEM file. 
Since both files are in the same sequence, once all ITEM 
master records are processed, any sales records which still 
remain in the SALES file must be either records which 
match the last primary record processed, records for which 
there is no valid item number, or total records which are not 
to be matched. 


=) 


ITEM File 


Figure 6-26. Processing a Matching Records Job After End of File 
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When the /* record in the primary file is read, the program 
checks the other file. The two SALES records for item 321 
match the last primary file ITEM record processed. Thus, 
they are automatically processed. The next record in the 
SALES file, a total record without match fields, will cause 
the LR indicator to be turned on, and the program will 

end. However, if an end of file entry was not assigned to 

the primary ITEM file, or if the end of file entry was assigned 
to the secondary SALES file, all records in the SALES 

file will be read and processed. 





/ * 
TOTAL —~——~ 
Not 
468 Processed 
468 
TOTAL 


Records Processed 
After End-of-File 
Reached in ITEM 





nel File 


J 





Match Fields And Multifile Processing 6-33 


USE OF MATCH FIELDS AND CONTROL FIELDS IN 
THE SAME FILE 


ITEM DESCRIPTION QUANTITY LOCATION 


In the previous example, the ITEM and SALES files were 
matched according to an item number field so that individ- 
ual sales could be printed under the item description. Sup- 
pose you also wish to have the sales for each item totaled 
and printed, as shown in Figure 6-27. 


To perform total operations on a group of records, it is 
necessary that control fields be assigned to distinguish one 
group from the next. For this program, the same item num- 
ber field used for matching the records would be specified as 
a control field on the Input sheet (Figure 6-28). Although 
your files may contain both match fields and control fields, 
there is no relationship between the two functions per- 
formed. Even if the same fields on a record are used as both 
match and control fields, the only similarity is that the same 
data will be used in performing each function. 


Match fields are checked first to determine from which file 
the next record is to be processed (see Figure 6-29). In ef- 
fect, the matching record function is creating one file for 
processing by merging the data from two files. (Of course, 
after processing, the two files are automatically separated 
again into the appropriate stackers.) Figure 6-27. Printing Totals for Matching Records 





In addition, comparison of the match fields determines 
whether the MR indicator will be turned on or off for proc- 
essing of the selected record. As discussed previously, the 
MR indicator is to be on for processing of a primary file 
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Figure 6-28. Assigning the Same Field as a Match Field and as a Control Field 
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Figure 6-29. RPG I! Logic of Obtaining Totals for Matching Records 


record only if there is a matching record in the secondary 
file. Likewise, if a secondary file record is selected, MR is 
to be on for its processing only if a matching record from 
the primary file has already been processed. If an unmatched 
record is selected, MR is set off, of course. At this point, 
however, the matching record function only determines how 
the MR indicator is to be set; the status of MR is not actual- 
ly changed yet. 
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Once the matching record function has selected the next 
record to be processed, the control level function then con- 
siders the records as one file in determining if a control 
break has occurred. This check is made before the selected 
record is processed and, thus, before the MR indicator is 
set for the record just selected (see Figure 6-29). The con.- - 
trol field (item number) on the selected record is checked 
to see if it is different from that on the previously proc- 
essed record. If it is the same, no totals are to be printed; 
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so the MR indicator is set, the QTY accumulated into 
TOTAL, and the individual record is printed. However, if 
the item number is different from that on the previously 
processed record, this means that all individual sales for 
the last item number have been printed. The change in the 
control field causes a control level indicator (L1 was as- 
signed) to be turned on. Any total calculations and total 
output (operations conditioned by the control level indica- 
tor) are then performed for the previous control group. In 
this case, the total of all sales for the previous item are ‘i 
printed. | 


When total operations are performed, the selected record 
has not been processed yet. Therefore, during total time, 
MR is still set for the previously processed record. Once 
total operations are completed, MR is then set for the 
selected record (the first record in the next control group) 
so it can be processed. 
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Whenever a control field changes (control break), a control 
level indicator is automatically turned on. Furthermore, 
whenever a contro! level indicator is on, total operations 
will be performed. In a matching records program, however, ™ 
there may be times when a control break occurs and you 

don’t want total operations to be done. Thus, you must 

specify that total operations are to be performed only under 
certain conditions. : 


For this program, sales are to be added and the total printed 
only if there isan. {TEM master record with matching SALES 
records for that item. In such a case, MR would have been 
set on for the last SALES record of the group. MR would 
still be on, then, when the control break occurs. Thus, detail 
operations to accumulate sales should be performed when- . 
ever MR is on and the total operations to print the TOTAL 
should be conditioned to be performed only with L7 and _ 
MR on (Figure 6-30). 
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Figure 6-30. Controlling Performance of Total Operations in a Matching Records Program 
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Since there can be unmatched records in either file, you can 
have an ITEM record with no matching SALES records or 
invalid SALES records for which there are no matching ITEM 
master (see Figure 6-31). Although a control break would 
occur following the processing of the unmatched records, 
you don’t want total operations to be performed. The MR 
indicator would be off for the unmatched records. There- 
fore, if you condition total time output specifications with 
L1 and MR on, total time would be bypassed for such cases. 


DETERMINING WHETHER FILES SHOULD BE 
PRIMARY OR SECONDARY 


A basic question arises in any multifile processing application: 


Which file should be designated the primary file and which 

is to be the secondary file? Since almost all multifile pro- 
grams involve the use of match fields to determine processing 
order, an understanding of matching record logic is generally 
essential for determining which file should be the primary 
file. 


Since files vary among applications, we can’t state absolutely 
that a certain file is always to be primary or secondary. 
However, now that you understand the basic matching rec- 
ords concepts, the following points may help you to make 
the best file designation. 


If the match fields on records from two or more files are 
compared and found to be the same, the primary file rec- 
ord is always selected. Furthermore, the primary file would 
be given priority if none of the available records contained 
match fields. In general, then, if all match conditions are 
the same, the primary file record is the first processed. 


With this idea in mind, we can say that if data from file A 
must be available to the program before file B can be proc- 
essed, the file containing the necessary data (A) should be 
designated as the primary file. For example, say you have 
two files to process to do a customer billing application. The 
customers’ names and addresses are recorded in one file while 
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the customers’ transactions are in another file. A name and 
address is to be printed on a bill before a customer’s charges 
and credits. The name and address record must be available 
for output and, thus, must be processed before the related 
transaction cards. In this case, the name and address file 
should be specified as the primary file. 


Let’s consider another case in which one file is to be used 
only as input while the other file is to be used for both in- 
put and output. In other words, the program requires one 
input file to be read and one combined or update file to be 
both read and written or punched. Usually, information 
from the input file would be necessary to calculate the data 
to be output to the combined or update file. Or, perhaps 
the actual input file data is to be output to the combined or 
update file. Either way, the combined or update file should 
be specified as the secondary file, so the data from the pri- 
mary input file is available before the output is done. 


In general, the type of data which must be available before 
processing another file is permanent record information, 
such as would be found in a master file. For instance, an 
employee's hourly wage from a master file is necessary be- 
fore the computer can use the number of hours worked 
from an employee detail file to calculate net pay. There- 
fore, a master file is often the primary file, while a detail 
or transaction file is the secondary file. Of course, this is 
only a guideline and should not be considered the rule for 
all situations. 


As a final point, if the first record in one of the files must 
be the first record processed in the program, you must make 
sure that this record would be selected. To do this, first 
decide which file you think should be primary and which 
secondary, according to the suggestions presented. Then, 
determine which record would be selected first in the pro- 
gram by the RPG II logic of matching records. If the record 
which would be selected is not the record which must be 
processed first, the primary and secondary file designation 
should be switched. 


LR turned on. MR on from previous record 

so total operations done for previous control group. 
(SALES for 156 totaled and printed). Job is then 
ended. . : 











S 156 25 


MR turned on 






S 156 14 


MR turned on 


L1 turned on. MR off from previous 
record so total operations skipped. 
MR then turned on for this matching © 
record. es 


L1 turned on. MR on from previous 
record so SALES for 124 are-totaled ; 
and printed. MR then set off for 

this unmatched record. 





UNMATCHED 













S$ 124 18 


MR turned on 


36 





S 124 


MR turned on 
*e L1 turned on. MR off from previous 

record so total operations skipped. Then 

MR turned on for this matching record. 


L1 turned on. MR still on for © 
previous record so SALES for 101 
are totaled and printed. MR then . 
set off for this unmatched record. 


UNMATCHED RECORD 
as 





S 101 





MR turned on 





S 101 23 


MR turned on 









S 101 47. 

bot 
ITEM QTY . 
MR turned on 





L1 turned on automatically for 
first record. Total operations are 
skipped in first program cycle, _ 
however. MR then set on for 
“this matching record. 


SALES File 


(Secondary File) 


ITEM File 


(Primary File) 


Figure 6-31. Use of MR Indicator to Determine Whether Total Operations are to be Performed 
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Review 6 


1... What are match fields used for when assigned to a single file? 


2; If a record type has two match fields, which match field is assigned M1 and which is 
assigned M2? 


3. Referring to the following Input sheet, indicate the errors in assigning rvieteh fields 
and the reasons the specifications are in error. 





RPG INPUT SPECIFICATIONS caUeA 
IBM International Business Machine Corporation 


; p23 _75 76 77 78 79 80 
ree wren [Sm OTT 
wen Pre | TP EL LL ir 


Record Identification Codes 





frm teon | Location 


%| Field Name 
From 
43/44 45 46 47]48 49 50 51[52153 54 55 56 57 58/59 60 


POEL rere 
rela ns [ey ea EMen it 


Filename 


Record Identifying Indicator 
ee 


Form Type 
Option (0) 
Character 


c/2/0 
Field Record Relation 


Decimat : 
Control Level (L1-L9) | 
Matching Fields or 
Chaining Fields 





a 


if 


raf RS Ry 
Mm. YOR 





TCCOREECRRERIE 
COCESCST Re 


4. Must match fields be assigned to all record types in a file? 


5. Given the following data about a file named EMPLOYEE, code the input specifica- 
tions which describe the record types in an OR relationship: 


~ Record type 01 identified by the character A in position 96. 
Record type 02 identified by the character B in position 96. 


FieldName Record Positions © Record Type 
NAME 6-15 record type 02 only 
DEPT 1-4 ~ both record types » 
CODE B89 ' record type 01 only 
ADDRES 16-30 record type 02 only 
EMPNUM (match field) 42-45 | both record types 


6. | What are match fields used for when assigned to multiple input, update, or combined 
files? 
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Refer to:the following program cycles to answer questions 7 and 8: 


we ce yen ° e 
Detail Calculations = 3 = Detail Calculations 





and Output . a ' Record 1 selected. : and Output : Record 2 selected 
e : e 
Total Calculations | o ' Total Calculations 
and Output and Output 
en : ves : r _@.. e 
~ PROGRAMCYCLE1 PROGRAM CYCLE 2 


Ae ee 7. __ When is the MR indicator set on and off for the first record selected for processing? 
8. When is the record identifying indicator for record 1 set on and off? 
9. Beline an unmatched record. 


se . 10. lf a primary file record is selected for processing, what condition must be met for the 
7 ae , MR meleator to be set on for at record? 


11, If a aaa file record | is ssiacted for processing, ‘what condition must be met for . 
the MR indicator to be set on for that record? 


he 12. Pectin’ an ITEM ¢ file read fon the M MFCU or MFCM contains two record types. Which 
specification line on the following Output sheet is correct in order to stacker select 
pict, 3. = “unmatched records of record type 01 into stacker 3? What are the other two stacker 
selection specifications incorrect? 


RPG = OUTPUT SPECIFICATIONS Gx21-9090 Unt 080" 
IBM International Business Machine Corporation i : : ee ‘ : ‘ : 
1-2 75 76 77 78 79 80 
rev eg ce 
see mL LJ ete 


a lo Field Edit 
Filename ; oe. ah ta End No Yes . c tL Zero 
2s nite = Positon No No D iM Suppress 





13. Anitem number field is assigned as a match field for processing the two files shown. 


Me 


Item 
Number 


Primary File 





would be processed. 


Identify the matching records (records for which MR is on), the unmatched records, 
~ and the records with no match field assigned. 












ST 051309 





HAUS 


Item 
Number 


Secondary File 


) 14. Referring to the files shown in question 13, specify the order in which the records 


15. What does an E in column 17 of the File Description sheet Indicate? What does an 
Aor Din cole 18 indicate? . 


16. What do the following input specifications cause to happen? 





IBM tnternational Business Machine Corporation 


Program 


RPG INPUT SPECIFICATIONS Gees mee 


| © 
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Br 76 77 78 79 80 


rn ew PC ecto 


Filename 
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oman | Wal | wat | Pel om TIL 
BEE 


it Tae 6 


Record Identifying Indicator 
oe 


. Record Identification Codes 


ji~] 


hs 
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terete 


pele 

beta 
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Decimal 
Control! Level {L1-L9) 
Matching Fields or 
Chaining Fields 

Field Record Relation 


| Fisteatin | Location Field 
Indicators 
S| Field Name 3° 
From — : i 
344 45 46 47/48 49 50 51/52/53 54 55 56 57 58159 60/61 62 63 64/65 66 


||| 6 ReGzoweluMel | tt ttt tt | 
PCH 
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Review Problem 


The data processing department is to prepare a weekly labor distribution report showing 
the total number of hours worked by each employee, as well as the total number of hours 
worked by all employees within a department. Therefore, the report must be organized | 


_. by department number and by man number within a department. 


Two input files are necessary to provide data for the report: 
a. PMSTER is a master payroll file containing three types of records: 


@ Date record — first record in file. 
@ Department name records, 
@ Employee master records. 
The employee records are in ascending sequence by department number and by man 
number within a department. A department name record appears within the file immed: 
ately before the group of employee records for that particular department. 

b. LABOR is a file of daily records containing the number of hours an employee worked. 
Since each employee's daily hours are recorded on a separate record, there will be more 


than one LABOR record for each employee. 


The LABOR file is iso in ascending sequence by department number and by man num- 
ber within a department. 


PMSTER File — 3 Record Types 


Date RecordLayout = =. , 
DATE 
2345 6 7/8 8 oH 12 12 44 18 96 17 $8 19 20 2t 22 23 24 29 26 27 28 29 90 31 32 33 34 3S 36 37 90 39 40 41 42 43 


Department Name Record Layout 






1D. _ FIRSTI SECNDI 
CODE 


DPTNME LAST. 
2345 6 F @ BP 1 1 12 19 4 1S 1 7 1 1-20 21 22 28 20 £7 28:28:30 31" 32; 39 (94. 38, 38:37 9059840! 4148 


Department Name . 








Manager’ s Name 


Employee Master Record Payout 


1.D. DEPT MANNO 
CODE . 







NAME 


9 1 If 12 13 6 1S 16 17 WwW HD 20 Bt 22 23 24 23 26 27 26 28 30 






RATE 
vn 32 33 4 38 


Employee Name Hourly 
Number Rate (2 decimal 
positions) i 





LABOR File ~ 1 Record Type 


DEPT MANNO HRSWKD 


eS eee 32 33 34 33 36 37 38 39 40 41 42 43 


Hours 
Worked 





In processing the two files, there should be an employee master record related to all LABOR 
records. In fact, more than one LABOR record will match the same employee master record 
from the PMSTER file. However, it is possible that the LABOR file contains the following 
unmatched records: 


@ Records with errors in match fields. 


@ Records for new employees for whom employee master records have not yet been 
created. 


If you read the LABOR file from the MFCU or MFCM, unmatched LABOR records should 
be stacker selected into stacker 3. Processing should end when the last record from the 
LABOR file has been processed. | : 

For this program, see if you can code the following: 

1. File description specifications (read the files from MFCU, MFCM, or DISK). 


2. Input specifications. 


3. Output-format specifications necessary to stacker select unmatched LABOR cards 
using the MFCU or MFCM. 
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Answers To Review 6 


1... Match fields are used to sequence check cards within a file. 
2. The higher entry, M2, is assigned to the more important field. 
3. Reasons for specification errors: 


Line 07 — .Match fields of the same level must be the same length. Also, fields 
having the same name must be the same length, regardless if they are 
assigned as match fields or not. 

Line 08 — Match fields of the same level must be in the same format (alphameric 
or numeric) if the fields have the same name. Also, fields with the 

_ same name must be in the same format (alphameric or numeric), re- 
gardless if they are assigned as match fields or not. 

Line 10 — Every record type assigned match fields must contain the same number 

~. . Of match fields. 


4. | No. Remember that ator types without match fields are 2 selected before record 
types with match fields. 


5. All fields which are common to all record types must be described first. All fields re- 
lated to a particular record type are then described together as a group. Following 
the common fields, fields related to either record type 01 or those related to record 
type 02 may be described next, as follows: 





5 ee. RPG INPUT SPECIFICATIONS Panedin USA. 
IBM International Business Machine Corporation 


: 75 76 77 78 79 80 
= wom [oe] [1 [>] =n norm 
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Field 
Indicators 
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Filename Field Name 


Form Type 


Number (1-N) 
Option (0) 
Record Identifying Indicator 
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Matching Fields or 
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Field Record Relation 
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10. 


11. 


12. 


13. 


14. 


Page of GC21-7567-2 
tssued 21 December 1979 
By TNL: GN21-5709 


Match fields are used for two purposes: 
a. Sequence checking the cards in each file 
b. Matching records between the two files to determine the order of processing 


MR set on between total time and detail time operations during program cycle 17. 
MR set off between total time and detail time operations during program cycle 2. 


Record identifying indicator set on immediately after record is selected during pro- 
gram cycle 1. 

Record identifying indicator set off following detail time operations during program 
cycle 1. 


An unmatched record is a record in either input file which does not have a matching 
record (same match field) in the other input file. 


There must be a record in the secondary file with the same match field(s) as the 
record in the primary file. 


The match field(s) on the secondary file record must be the same as the match field(s) 
on the last primary file record processed. 


Line.O3 is a correct specification for stacker selection of unmatched records. 

Line 01 is incorrect because there is no record identifying indicator specifying the 
type of record to be stacker selected. . 

Line 05 is incorrect because stacker selection of a record on the basis of a matching 
or not matching record condition should be done at detail time, not at total time. 


Matching records are records from both files containing item numbers 101, 107, 
212, and 298. 


The three unmatched records from the primary file contain item numbers 105, 105, 
and 267. The one unmatched record in the secondary file contains item number 187. 


The *DATE record from the primary file and the two name records from the secondary 
file are records with no match fields assigned. 


The records would be processed in the following order: 





Primary File Secondary File 
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Page of GC21-7567-2 


Issued 21 December 1979 


By TNL: GN21-5709 
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15. 


16. 


An E means the program should check that file for end of file. If end of file is 
reached (a /* record read), usually processing of records is stopped. However, if 
end of file is reached in a matching records program, the matching records and 
records with no match fields from the other file are processed before the pro- 
gram is ended. 


An Aor D entry indicates that an input file is in ascending or descending sequence 
according to the match field(s) on the records. 


First, the REGION match fields are compared to determine if there is a matching 
record condition and, thus, which record to process. Next, the contents of the 
REGION field are checked on the record selected to determine if a control break 
has occurred and, thus, if L1 should be set on. 


Solution to the Review Problem 


File Description Specifications 
a. MFCU or MFCM files: 


Is 


File Description Specification 


File Addition/Unordered 


Mode of Processing 


Number of Tracks 


Extent Exit 
for DAM 
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b. Disk files (sequential): 


File Description Specification 


File Addition/Unordered 


Mode of Processing 


Number of Tracks 
for Cylinder Overflow 


Extent Exit 
for DAM 


2 
ss 
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2:3 
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»3 
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sz 
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ec 
3% 


File Designation 


Number of Extents 


Name of 


Record Address Type 


Label Exit 


Filename 


Type of File 
Organization 


File Format 


or Additional Area 


Continuation Lines 
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Input Specifications 


2. 
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Output Specifications 


3. 


SPECIFICATIONS 
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Chapter 7. Programmed Control of Input and Output 


CHAPTER 7 DESCRIBES: 
How to alter the order of processing input files using FORCE. 
How to read one or more records per cycle from a demand file. 


- How to do repetitive or exception output during calculations. 


scrORE READING <hIe CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
Multifile processing. 
Look-ahead. | 
End-of-file condition. 
*PLACE. 


RPG Il program logic (Chapter 1). 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: © 


Nee 


RPG It FORCE spetaieh code. 
Using FORCE with the look-ahead feature. 
Using the RPG I! READ operation code to process demand files. 
~...RPG Il EXCPT operation code. 
Nate: You can use the review questions contained in Review 7 at the end of this 
chapter to test your comprehension of each topic in the chapter. Questions are 


grouped according to the topic to which they apply. Answers follow the review _ 
questions. 


J 
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INTRODUCTION 


Normally, records are read, identified, selected for process- 
ing, and output according to the fixed logic of the RPG I! 
object program. Sometimes, however, you need to have 
direct control over the input and output of your program. 
RPG II provides several operation codes which give you this 
control. By using the FORCE operation code in your own 
calculation routine, you can override normal RPG I} multi- 
file logic for selecting input records for processing. You 
can also do certain kinds of input and output during calcu- 


lation time by using the READ and EXCPT operation codes. 


Note: The CHAIN operation code also allows programmed 
control of input and output operations. The CHAIN opera- 
tion is explained in /BM System/3 RPG I/ Disk File Pro- 
cessing Programmer’s Guide, GC21-7566. 


ALTERING THE ORDER OF PROCESSING FILES 
(FORCE OPERATION) 


RPG II uses two methods to determine the order in which 
records are processed in a multifile program. 


® If match fields are not specified for either file, all records 
in the primary file are processed, followed by those in 
the secondary files in the order defined on the File De- 
scription sheets. 


@ When match fields are assigned, the RPG II logic of 
matching records determines from which file the next 
record is to be processed. 


The order of processing determined by RPG II logic is ap- 
propriate for most of your multifile programs. However, 
for certain programs, it may be necessary to have some of: 
the records in the two files processed in an order other than 
that in which RPG II logic would select the records. 


A record can be processed out of order only if you indicate 
to the program that the file containing that record is to be 
forced. To do this, you must code additional specifications 
to override normal RPG II multifile logic. 


Regardless of how your files are organized, the following 
situations require that you alter the order of processing: 


Vs Match fields cannot be assigned to the files and you 
wish to: 
a. Alternate processing between two files. 
b. Process a primary file record followed by a par- 
ticular number of secondary file records. 
c. Process.a secondary file record only when it 
matches a primary file record. ° . 


2. Match fields are assigned to both input files. You 
wish to process one primary file record, followed by 
matching secondary file records, then the rest of the 
matching primary records. 


To alter the order of processing, you must first determine 
which file is to be processed—when and under which con- 
ditions. Once you know the order, the next step is to deter- 
mine, for a particular programming cycle, whether the RPG 
Il logic will select the appropriate record or if you must 
force the processing of that record. 


The first record to be processed in any program can only be 
selected by RPG II logic in the usual way. Thereafter, to 
alter the order of processing, you tell the program to force 

a record from a file which would not ordinarily be processed 
next. Once the forced record is processed, and providing an- 
other record is not forced, the RPG II logic selects the next 
record in the usual way. This is the record which would 
have ordinarily been processed if the other file had not been 
forced. 


. Specifying the Next File to Process 


To process a record out of its normal sequence, you specify 
on the Calculation sheet the FORCE operation code and 
the name of the file which is to be forced in the next pro- 


gram cycle (Figure 7-1). 


wy 


NN 


ee 


x 


Assuming a record type 01 from the primary file is being 
processed, the calculation on line 01 is performed. The next 
detail-time calculation specification for record type 01 indi- 
cates that the secondary file (SECOND) is to be forced. The 
FORCE does not occur immediately, however. This speci- 
fication only tells the program to remember that a record 
from the file SECOND is to be processed next. Any addi- 
tional calculations and/or output for the record being proc- 
essed are performed first to complete the present program 
‘cycle. 


At the beginning of a normal program cycle, RPG II logic 
looks at the two records available in order to select the one 
to process during that cycle. However, if the record from 
the file which would not normally be selected is to be proc- 
essed, this must be indicated to the program before the be- 
ginning of the cycle. Ifa file is to be forced, there is no 
need for RPG II logic to compare the records and make a 
selection. This is the reason that, if a file is to be forced, 
the FORCE must be indicated during the program cycle 
immediately before the cycle in which the FORCE is to 
occur. 


Depending on your program, you may not have to force a 
record in every program cycle. For such situations, you 
must indicate when the FORCE is to be done by speci- 
fying conditioning indicators in columns 9-17 of the Calcu- 
lation sheet (Figure 7-1). Whether the FORCE is to be per- 
formed in the next cycle or not may depend on any of sev- 
eral conditions: 


@ The type of file or record type being processed at the 
time. © 


@ The number of records which have been processed. 
@ The result of a calculation performed. 


@ The contents of a field on the record being processed. 


@ The contents of a field on a record which has not been 


processed yet. 


With these points in mind, let’s discuss a job in which you 
can determine if the order of processing must be altered on 
the basis of the type of record being processed. 
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Figure 7-1. Specifying the File to be Processed in the Next Program Cycle 
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Alternating Processing Between Two Files 


The two files in Figure 7-2 each contain one record for every 
salesman in a company. The MASTER records are arranged 
in alphabetical order by salesman name; the MONTH file is 
arranged in ascending sequence by salesman number. Al- 
though there is no common match field, the records in the 
two files are, nevertheless, in a one-to-one correspondence. 
Salesmen numbers have been assigned such that they corres- 
pond to the order of the salesmen names. Thus, the first 
record in each file is for Baker (salesman #10); the second 
record in each file is for Costello (salesman #20), and so on. 


/* 





Commission Date 
Rate 


MASTER File 


Figure 7-2. Files to be Alternately Processed 
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The two files are to be processed to determine the amount — 
of commission earned by each salesman. To do this, a sales- 
man’s commission rate from his MASTER record must be 
multiplied by the amount of his sales contained on his 
MONTH record (Figure 7-2). The calculated commission is . 
then recorded in the salesman’s MONTH record. 
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The two files are defined and the records described with 


: the specifications shown in Figure 7-3. MASTER, the pri- 


} mary file, is assigned record identifying indicator 01. Indi- 
“ cator 02 is assigned to the secondary file, MONTH. Since 

MONTH is a card file to be used for both input and output, 

it is defined as a combined file. (MONTH could also be de- 


fined as an update file, on another device.) 
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This program must process the two files alternately; that is, 
every primary file record processed must be followed by a 
secondary file record. Likewise, every secondary file record 
processed must be followed by another primary file record. 
In this case, the MASTER record for a salesman is read to 
make the commission rate available. His MONTH record is 
then processed, to calculate the commission and record the 
amount in the MONTH record. Then, the next MASTER 
and the next MONTH record are processed in the same way 
for the second salesman. 


File Description Specification 


Mode of Processing 
Length of Key Field or 
of Record Address Field 
Record Address Type 
Type of File 
Organization 
or Additional Area 
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Figure 7-3. Specifications to Define and Describe Files to be Processed Alternately 
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Since no match fields are assigned, RPG II logic would nor- 
mally process all records in the primary MASTER file before 


any of the secondary MONTH records. To alternate the files, 


you must tell the program to force a secondary file record 
every time a primary file record is being processed. When a 
MASTER record is being processed, record identifying in- 
dicator 01 is on. Thus, you should condition the FORCE 
operation to be performed only if 01 is on (Calculation 
sheet in Figure 7-4). 


At the beginning of the program, RPG II logic automati- 
cally selects the first record, which is a primary file record. 
Since 01 is on, the FORCE operation is performed; that is, 
the program notes that a MONTH record is to be forced at 
the beginning of the next cycle. 
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Figure 7-4. Conditioning Operations on Basis of Record Type 
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During processing of the forced record (02 on), the com- 
mission is calculated and recorded in the MONTH record 
(Figure 7-4). Only the specifications for record type 02 are 
done. Therefore, the FORCE operation is not performed. 


Since no FORCE was indicated in this cycle (02 on), RPG II 
logic again takes over to select a record, at the beginning of 
the next cycle. Thus, the second primary file MASTER rec- 
ord is processed (01 on). Processing of the files continues 
with the next MONTH record being forced and then another 
MASTER record being selected by RPG II logic until all rec- 
ords have been processed. 
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Forcing a Number of Records from a File 


In the last example, the FORCE operation was performed 
only if a particular record identifying indicator was on. 
Now let’s consider a case in which you condition the 
FORCE operation on the basis of whether a resulting in- 
dicator is on or off. 


Suppose you have a number of customers who periodically 
order items to be delivered from a central warehouse. One 
record is kept for each unit in stock in the warehouse, and 
another record for each customer’s order of a particular 
unit. 


Orders are processed according to the type of unit ordered. 
Therefore, fora particular run, the primary file (ORDER) 


contains all order records for only one type of unit, and the 


secondary file (STOCK) contains all in-stock records for 
that type of unit. 
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Figure 7-5. Files for Processing Customer Orders 


Page of GC21-7567-2 
Issued 21 December 1979 
By TNL: GN21-5709 


For this run, the ORDER file (Figure 7-5, insert A) contains 
the week's order records for television sets, unit number 
4607. The records show which customer placed the order, 
and the quantity of television sets wanted. The STOCK file 
consists of a separate record for each television set (unit 
4607) in stock (Figure 7-5, insert B). Each record provides 
the unit number, list price, and serial number of the item. 


There are two purposes for processing the files. First, you 
want an indication of which orders can be filled and which 
orders cannot be filled. Secondly, the STOCK file is to be 
kept up-to-date so it only contains as many records as there 
are television sets available. 
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Note: System/3 will allocate two decimal places in the list 
price, although a decimal does not appear in the field. 

The list price in the stock file is logically represented as 
$359.05. 
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The program should produce a printed report showing which 
orders can be filled, and the amount each customer owes 
(Figure 7-6). Thus, you must determine the amount due 

for each item and the total amount for each order. A rec- 
ord from each file must be available before you can calcu- 
late the information. 


Files for this program must be processed in a specific order. 
The quantity ordered (QTY) from an ORDER record must 
be available first. This quantity is used to determine how 
many STOCK records are to be processed. When enough 
STOCK records for an order have been processed, the next 
ORDER record is selected to repeat the process. 


Looking at the two files, you can see that every record has 
a common field containing the unit number. It does no 
good to assign a match field to control processing order, 
because the unit number is always the same for every rec- 
ord. All records in the primary file would be processed 
before any secondary file records. 


Remember, there is no way you can control selection of 
the first record to be processed in a program. RPG II logic 
always selects a primary file record first when match fields 
are not specified. Since an ORDER record must be avail- © 
able first for this program, the ORDER file should be des- 
ignated as the primary file. 
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Figure 7-6. Printed Report Showing Customer Orders Processed 
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Controlling the Number of Times FORCE is Performed 


After RPG II selects and processes an ORDER record, you 
must FORCE the processing of a number of STOCK rec- 
ords. The quantity ordered (QTY) from the ORDER rec- 
ord is used to control the number of times you force second- 
ary file records. The quantity is stored in a field, called 
COUNT, to keep track of how many records are left to be 
forced for an order. Each time a STOCK record is forced, 
the number in COUNT is reduced by one. When COUNT 
reaches zero, enough STOCK records have been processed 
for that particular order. Then RPG II logic can again take 
over to process the next ORDER record (Figure 7-7). 


The calculation specifications shown for this program (Fig- 
ure 7-8) only determine if a record is to be forced in the 
next cycle. 


Assume the first ORDER record (record type 01) has been 
selected, making the quantity ordered (QTY) available. The 
first calculation specification (line 01) for this record type 
stores the quantity in the COUNT field. Then the program 
determines if any STOCK records are to be processed for 
this order (line 05). !f COUNT is greater than zero, indica- 
tor 27 turns on. With 27 on, line 06 is performed, indica- 
ting a STOCK record must be forced in the next program 
cycle. 
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At the beginning of the second cycle then, the first STOCK START 
record (record type 02) is selected (by being forced). Line 
03 is performed to reduce the COUNT by one for this rec- RPG II selects 
ord being processed. The COUNT is then compared to zero 
again (line 05) to determine if any more STOCK records are - 
to be processed for this order, 1f COUNT is still greater than 
zero (27 set on again), line O6 is performed again, indicating 
another STOCK record is to be forced at the beginning of 

the next cycle. 


ORDER record 














Have 
all stock 
records been 
processed for 
this 
order? 


During processing of the second STOCK record, COUNT is 
again reduced by one (line 03). Assuming COUNT is now 
at zero, the COMPARE operation on line 05 sets indicator 
27 off. With 27 off, the FORCE operation on line 06 is not 
performed during this cycle. At the beginning of the next 
program cycle then, RPG I! selects the next ORDER record 
from the primary file in the usual way. NO 


YES 


Is quantity greater 
than zero? 


FORCE a’ 


STOCK record 


Subtract 1 


from quantity 





Figure 7-7. Determining When Stock Records Must be Forced to 
Fill an Order 
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Figure 7-8. Controlling the Number of Times a File is Forced | 
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At this point, add the specifications for calculating the 
amount due and for printing the report (Figure 7-9). An 
ORDER record is selected first, making the QTY available. 
Calculation lines 01, 02, and 06 in Figure 7-9 are performed 
for this record (record type 01). First, a TOTAL field, to 
be printed for each group of customers, is set to zero (line 
01). Next, the quantity ordered is moved into the COUNT 


field (line 02). If COUNT is greater than zero, indicator 27 
is turned on (line 06), and line 07 is performed; the pro- 
gram is instructed to force a STOCK record at the beginning 
of the next cycle. Before forcing, however, the output speci- 
fications (Figure 7-9, lines 08-11) are performed to print 
data from the ORDER record. 
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Figure 7-9. Specifications to Process Customer Orders 
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Following output, the next cycle begins with a forced 
STOCK record (record type 02) being processed. The cost 
is added to a TOTAL field (line 03) to accumulate the total 
amount due on the order. 


Then, COUNT is reduced by one for the record being proc- 
essed (line 04). Once again COUNT is compared to zero 
(line 06) to determine if line 07 should be performed; that 
is, to determine if another STOCK record is to be forced 
for the next cycle. The COST and TOTAL calculated for 
the STOCK record are then printed, by performing the out- 
put specifications on lines 12-15. 


The record selected at the beginning of the next program 
cycle depends on whether a FORCE operation was indicated 
in the previous cycle. If calculation line 07 had been per- 
formed, another STOCK record would be processed (by be- 
ing forced). If not, RPG I! would select the next ORDER 
record from the primary file. | 


Controlling Processing After Reaching End of File 


In a multifile program, end of file entries can be specified 


for any, all, or none of the input files. If an end of file entry | 


is specified for only one file, processing stops after all 
records from that file have been processed. (Remember, 
however, if match fields are assigned to the files, the pro- 
gram continues to process the records which match the last 
record processed or which have no match fields.) If end of 
file entries are specified for all or for none of the input files, 
processing continued until all records in all files have been 
processed. 


For this program, suppose ORDER and STOCK are card 
files, and processing must continue until both reach end of 
file. However, if one file runs out before the other, you 
don’t want to perform the usual calculations and output for 
the remaining file. The remaining cards must be processed 
in another way; that is, by selecting them to a special stack- 
er. If all orders are filled, any remaining STOCK cards 
should be selected to stacker 3. If there aren’t enough items 
in stock to fill all orders, any remaining ORDER cards 
should be selected to stacker 2. 


To continue the program until both files have been com- 
pletely processed, specify end of file entries on the File Des- 
cription sheet, either for both of or for neither of the two 
input files (Figure 7-10). By doing this, the LR indicator 
won't be set on to end the program until! the last record of 
the last file has been processed. 


With end of file specified for both files, let’s consider what 
will happen when only one of the files reaches end of file 


_ (see Figure 7-9). First, suppose the STOCK file reaches end 


of file before all ORDER cards are processed. Since both 
files are not at end of file, processing will not stop. Instead, 
after processing the next ORDER card, the program will try 
to force the appropriate number of records from the STOCK 
file. With no more STOCK cards to force, another ORDER 
record will be selected. Once again, the program will try to 
force STOCK records for that order. The process continues 
until all primary file ORDER records have been processed. 
Furthermore, every time anew ORDER record is processed, 
it is printed on the report and the card goes into stacker 1, 
as if the order were being filled. 


A similar problem arises if the ORDER file reaches end of 
file first. Suppose the last order has just been filled. 
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Figure 7-10. Continuing Processing Until Both Files Reach End-of-File 
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f 


After processing the last STOCK card for that order, no formed instead. Reading a /* card from a file will not neces- 


more STOCK cards are to be forced, so RPG II logic tries | sarily indicate that end of file has been reached in all files. 
to select the next primary file ORDER record. In doing so, © The LR indicator is turned on only when the /* card of the ~ 
the /* card from the ORDER file is read. Since the program last file has been read. Therefore, a trailer card should be 
is to continue until both files are processed, RPG II logic placed at the end of each file (Figure 7-11), before the /* 
automatically processes the remaining records in the other card, to indicate when all cards of the file have been proc- 
file (STOCK). As each remaining STOCK record is processed, essed. When a trailer card is read, the record identifying in- 
the calculations and output for that record type are per- dicator associated with that card turns on to indicate which 
formed and the card goes into stacker 4, as if the record file has been completely processed. For this program, the 
were being used to fill an order. trailer card in the ORDER file will turn on indicator 03, 
while the trailer card in the STOCK file will turn on indi- 
Although processing is to continue until both files reach cator 04. 
end of file, you must have a way of determining when the 
first file runs out and which file it is. This is necessary so Let’s look at the completed calculation and output specifi- 
that normal calculations and output for the remaining cards cations for this program (Figure 7-12) to understand how 
can be bypassed and stacker selection specifications per- the trailer cards are used to control processing. 
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Figure 7-11. Use of Trailer Cards to Control End-of-File Processing 


ae 


Assume the trailer card from the ORDER file (record type 


03) is read, indicating all ORDER cards have been processed. 


When record identifying indicator 03 is set on, you know 


that any remaining STOCK cards are to be selected to 
stacker 3. However, indicator 03 cannot be used to condi- 
tion the stacker selection. As soon as the trailer card has 
been processed and the first of the remaining STOCK cards 
read, indicator 03 is set off and record identifying indicator 
02 (for the STOCK card) is set on. Therefore, while the 
trailer card is still being processed, you must set on an indi-. 
cator which will stay on until the last STOCK card has been 
stacker selected. As calculation line 01 shows, record iden- 
tifying indicator 03 is used to SETON indicator 33. (The 
use of N34 on line 01 will become clear as the program is 
explained.) 


Now when a STOCK card is selected for processing, the pro- 
gram must determine if normal calculations and output 
should be performed for the record (record type 02). Since 
indicator 33 is on, normal calculations and output should 

be bypassed and the STOCK record stacker selected instead. 
To do this, all of the specifications for record type 02 could 
be conditioned to be performed only if indicator 33 is off 
(N33). However, to eliminate the extra coding and indicator 
testing, calculation line 02 instructs the program to skip the 


calculations when 33 is on, merely by branching to the end 
of calculations. Normal output for STOCK records is then 

conditioned so it isn’t performed if indicator 33 is on (out- 

put lines 10-13). Output line 19 then instructs the program 
to stacker select the STOCK card if 33 is on. 


Now, let’s assume the STOCK file runs out before the 
ORDER file. When the trailer card from the STOCK file 
(record type 04) is read, you know that the remaining 
ORDER cards must be selected to stacker 2. For the same 
reason as previously explained, the record identifying indi- 
cator of the trailer card cannot be used to condition the 
stacker selection. Therefore, record identifying indicator . 
04 is used to SETON indicator 34 (Figure 7-12, calculation 
line 04). 


In addition, while the trailer card is being processed, you 
must determine if the last order was completely filled. If 
there had been enough STOCK records to fill the order, the 
quantity in the COUNT field would have been reduced to 
zero. Therefore, when record identifying indicator 04 is on, 
COUNT field should be checked (calculation line 05). If 
COUNT is greater than zero, indicator 36 is set on. With 36 
on, a message will be printed indicating how many items of 
the last order could not be filled (output lines 14-17). 





IBM. jn ational Business Machine Corporatio! 


: 


And Factor 1 















Punching 
instruction 


Operation 


Ht ot 
a OR 
—O] 09 | 
A | 


sll 
al 
a 
ag 
aay 
Pah 
or 
Bay 
au 
an 
cE 
a 
eae 
Ei 
a 
Hh 
vt 


EID) |} tt | 


Figure 7-12 (Part 1 of 2). Controlling Operations at End-of-File 
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At this point, the first of the remaining ORDER cards is _ 
read. Since indicator 34 is still on, all calculations for the 
ORDER card are bypassed (see calculation line 06). The 
normal output for the ORDER record is to be performed 
only if indicator 34 is off. Thus, the printer output for rec- 
ord type 01 (output lines 06-09) is skipped and the record 
is selected into stacker 2 instead (output line 20). 


As you have seen, the trailer cards from each file are used 
to set on particular indicators. When the ORDER file 
trailer card (record type 03) is read, indicator 33 is set on. 
Likewise, indicator 34 is set on when the STOCK file trailer 
card (record type 04) is read. The indicator which is set on 
(33 or 34) is used to prevent certain operations from being 
performed and to cause remaining records in the other file 
to be stacker selected. 


Of course, reading a trailer card does not mean there are 
always cards remaining in the other file. For instance, as- 
sume all ORDER cards have been processed, but not all 
STOCK cards. When the ORDER file trailer card is read, it 


signals that the remaining STOCK cards should be stacker 
selected. As the STOCK cards are stacker selected, one-by- 
one, eventually you reach the end of STOCK by reading 
the trailer card from the STOCK file. At this point, both 
files have reached end of file, the LR indicator is automat- 
ically set on, and the program is ended. 


When the ORDER file trailer card is read (03 set on), then 
you want to know if the STOCK file has been completely 
processed. If it has, the STOCK file trailer card (record 
type 04) has already been read, and the indicator set on by 
04 (indicator 34) would still be on. With 34 on, there’s no 
point in having record type 03 set on indicator 33. Like- 
wise, if indicator 33 is on (ORDER at end of file) when the 
STOCK file trailer card (record type 04) is read, there’s no 
point in having record type 04 set on indicator 34. For this 
reason, the calculations on lines 01 and 04 of Figure 7-12 
have been conditioned by N34 and N33, respectively. 


As you know, the setting of an assigned indicator can de- 
termine whether a FORCE is to be performed or not in the 
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following program cycle. Either a record type, data on a 

record, or the result of calculations performed during proc- 
. essing of a record can set the particular conditioning indi- 
) cator on or off. 


In the examples presented thus far, something about a rec- 
ord which was currently being processed determined whether 
the conditioning indicator was set on and whether an un- 
processed record was forced. In the last example, the QTY 
field on the ORDER card determined how many STOCK 
records were to = forced. 


Look-Ahead to Determine Whether a File is to be Forced 


For some programs, you cannot determine whether a record 
is to be forced in the next cycle until you know something 
about the records which have not been processed yet. Thus, 
you must look ahead in one or both files at the next record 
which is not yet available for processing. In looking ahead, 
you may be checking to determine what record type is next, 
to see what data is on the next record, or to determine if 
the next record has the same match field as the record be- 
ing processed. What you find in looking ahead can deter- 
mine which file is to be processed next and, also, whether 
the file must be forced or not. 


Before considering the use of FORCE with look-ahead, how- 
If at all pos- 


ever, you should evaluate your system design. 


St 


sible, you should organize your files in such a way that the 
normal RPG II logic can determine the appropriate order of 
file processing. In this way, you do not have to code addi- 
tional specifications to control the order. Of course, from 
time to time you may have jobs in which you must use 
FORCE and look-ahead. 


Doing Matching Records Without Match Fields 


If two files are organized such that the same match fields 
cannot be assigned to the two files, you can still process the 
matching records together by using look-ahead fields and 
the FORCE operation. (This cannot be done, however, if 
the look-ahead file is defined as a combined or update file.) 
Look-ahead can be used to determine if certain fields (not 
assigned as match fields) on an unprocessed record match 
those on the record being processed. If they match, FORCE 
is performed to cause the matching unprocessed record to 
be selected next. _ 


As an example, assume a report is to be prepared showing 
the amount of each salesman’s sales and his quota. The re- 
port should also compare the total of district sales with the 
district quota. 


The two files available for this program are described in 
Figure 7-13. The primary file (MASTER) contains a district 
record (record type 01), followed by all salesmen’s MASTER 
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records (type 02) associated with the district. These are in 
turn followed by the next district record (01) and its related 
salesmen MASTER records (02) and so on. Although the 
records are grouped by district, all salesman MASTER rec- 
ords in the file are still in ascending sequence by salesman 
number. The secondary file (SALES) contains only one rec- 
ord type (03), a record for each individual sale. The SALES 
file is also in ascending sequence by salesman number. While 
the MASTER file contains a record for every salesman (as- 
sume there are no MASTER records missing), the SALES 
file may contain only one, several, or even no records for a 
particular salesman. 


To produce the report, the records should be processed in 
the following order: 


1. District record (record type 01). 

2. Salesman MASTER record (record type 02). 

3. All SALES records for that salesman (record type 03). 
4... Next salesman MASTER record. 

5. SALES records for that salesman. 


6. Next district record (after all salesman MASTER rec- 
ords associated with the first district have been proc- 
essed). 


There is no common field on all three record types which 
can be assigned as a match field to cause the records to be 

- processed in this order. Totals are to be accumulated by 

salesman number; but the MANNUM field is contained only 

on the salesman MASTER and SALES records. The district 

records do not contain this information. 


If the MANNUM fields are assigned as M1 match fields for 
only two of the record types, the records will be processed — 
in an incorrect order. Following the last salesman MASTER 
record (02 record type) for a particular district, the next 
record in the same file is another district card. Since dis- 
trict records have no M1 match field entry assigned (no 
MANNUM field), the district record is processed immedi- 
ately before the SALES records for the last salesman. 


Although this program cannot be done using match fields, 
you can match the records yourself by using the look-ahead 
capability to compare fields (Figure 7-14). The object is to 
match a salesman’s SALES record with this salesman 
MASTER record. Thus, the MANNUM field on a SALES 
record is defined as a look-ahead field. While processing a 
salesman MASTER record, you then look ahead (in calcu- 
lations) at the unprocessed SALES record to determine if 
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Figure 7-14. Using Look Ahead to Determine if Records Match 


the salesman number is the same as on the record being proc- 
essed. If they match, the FORCE operation code is used to 
process the SALES record as if RPG II logic were perform- 
ing a matching records job. You then continue to force the 
rest of the SALES records which contain the same salesman 
number. For each record, look-ahead is used to check the 
MANNUM field to determine if the SALES record should 

be forced. When look-ahead indicates that the next SALES 
record is for a different salesman number, the SALES rec- 
ord is not forced. Instead, RPG I! takes over to select the 
next primary file record which is either another salesman 
MASTER record or the next district record. f— 


Now that you understand the steps involved in this program, shown. To actually prepare the report, you would need file 


look at the specifications in Figure 7-15. The Input sheet description specifications to define the files and additional | 
describes the records in each file and defines the look-ahead calculation and output specifications to accumulate totals 
field for the SALES records. Only the calculations neces- and print the data. 


sary to determine which record is to be processed next are 
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Figure 7-15. Using Look Ahead to Match Records 
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Processing a Primary, Then Matching Secondary Records 
Before Matching Primary Records 


Another reason for looking ahead to determine which rec- 
ord to process next is when you want to process the files in 
an order other than the usual order of matching record 
logic. In such cases, all files must have match fields. The 
match fields on the next records available for processing 
are looked at to determine which record will ordinarily be 
selected and, thus, if it is necessary to force a record in- 
stead. 


To illustrate altering the order of matching record logic, 

let’s consider a sample billing program in which the records 
are to be processed in a particular order. However, note that 
the example is presented only to show you why and how 
look-ahead fields are used to determine whether a particular 
file should be processed. Actually, the desired results could 
also be obtained by processing the records in a different 
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| Figure 7-16. Files With More than One Matching Record 
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(Name and Address) 


order using the normal RPG 11 logic. We are not necessarily 
suggesting that your files be organized in the same way for 
your billing purposes. In fact, it is possible that the files for 
the sample program could be organized in a different way 
such that look-ahead with FORCE would not be necessary 
to process the records in the desired order. 


Organization of the Files: The two files for the billing ap- 
plication (Figure 7-16) can each contain two record types. 
The primary file (FIRST) contains a name and address rec- 
ord for every customer (record-type 01) followed by the 

customer’s charge record (record type 02) if any purchases 


were made during the month. The secondary file (SECOND): 


contains one record for every customer showing his previous 
balance (record type 03). If the customer is entitled to a 
discount, a record containing his discount rate follows the 
balance card. As you can see, both files are in ascending se- 
quence according to a common match field containing the 
customer number. 
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File Description Specification 


plication. As entries in column 18 of the Input sheet show, 


The specifications in Figure 7-17 define the files for this ap- 
record type 02 (charge records) in the primary file and rec- 
ord type 04 (discount record) in the secondary file may or 
may not be present for a particular customer. The use of 
the look-ahead fields defined on lines 11-12 and 19-20 will 
become clear as we explain the program. 
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@ Figure 7-17. Force With Look Ahead: Process Primary, Them Matching Secondaries Before Matching Primaries 
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Determining the Order of Processing: To produce a bill, 

a customer's name and address are to be printed, followed 
by his previous balance (Figure 7-18). Any additional 
charges for the month are to be added to the previous bal- 
ance to obtain a new balance. Some customers are entitled 
to a discount, which must be determined before adding the 
monthly charges to the previous balance. 


If the two files are processed by RPG II logic according to 
matching records, all matching primary file records are proc- 
essed before any matching secondary file records. In other 
words, first the name and address record is selected, fol- 
lowed by any charge records. Only after processing all the 
primary records for a particular customer are his balance 
and discount records processed. 


Providing a customer has no charge records, the order of 
processing determined by RPG II is correct. That is, after 
the name and address record (the only primary record with 
the same match field), the balance record from the second- 
ary file is processed. If there is a discount record with the 
same match field, it is then read, even though the discount 
data is not necessary when there are no charges. 


On the other hand, for customers who have incurred charges, 
the order of processing the matching records must be altered. 
Instead of processing all matching primaries before the match- 
_ ing secondaries, only the first primary record is processed. 
The matching secondary records are then processed, fol- 
lowed by the remaining matching primary records. 


Determining When to Force A File: The calculation and 
output specifications to process the records and print the 
bills are shown in Figure 7-19. For every customer group, 
the name and address record (record type 01) from the pri-. 
mary file is read first and printed at the top of the billing © 
form. RPG II logic automatically selects this primary rec- 
ord as the first to be processed. 


You want customer’s balance record (record type 03) from 
the secondary file to be processed immediately after the 
name and address record. What you must determine then, 
while the name record (record type 01) is still being proc- 
essed, is whether the balance record can be selected normal- 
ly or if it must be forced. You know that if there is a charge 
record for this customer in the primary file, it has the same 
match field as the name and address record. Furthermore, 
if there is a charge record with the same match field, this 
record will be selected for processing rather than the sec- 
ondary file balance record. Thus, while processing the name 
record, you must look-ahead at the next available primary 
record to determine if its match field is the same as the 
match field of the record being processed. To do this, line — 
01 of the calculation specifications (Figure 7-19) compares 
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ITEM QTY CHARGE PREV.BALANCE $ 7.54 


_ Figure 7-18. Bill Showing Order in Which Data Must be Printed 


the look-ahead match field (NXTNUM) on the primary file 
record not yet available to the match field (CUSNUM) on 
the name record being processed. If the fields are equal (in- 
dicator 21 set on), you must force the balance record (line 
02 of Calculation sheet). 


While the balance record is being processed, you must de- 


termine from which file the next record is to be processed. 


To do this, calculation line 05 is performed. If there is a 
discount record in the secondary file for this customer, the 
match field on the next available secondary file record will 
be equal to the match field on the balance record being 
processed. Thus, the look-ahead match field (NXTCST) for 
the secondary file is compared to the balance record match 
field. If equal, indicator 22 is set on, indicating the next 
available secondary record (a discount record) should be 


_ processed. Whether to force the discount record depends on 


whether there are still primary file records which match. If 
there were charge records in the primary file, the balance 

record being processed was forced and, thus, indicator 21 is 
still on. 
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@ Figure 7 
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Programmed Control of Input and Output 


The FORCE of a discount record on calculation line 06 is 
conditioned, then, by two resulting indicators: 22 on means 
there is a discount record to be processed and 21 on means 
that the discount record must be forced since the balance 
record was forced. 


After determining which file is to be processed next and, 
then, whether that file is to be forced, output processing 
continues for the record being processed. That is, the bal- 
ance is printed on the bill. 


Providing a discount record is present, this record is proc- 
essed next. No calculations and output are performed for 


this record, however. The discount rate (DSRATE) is merely 


. stored so that data can be used to calculate discounts when 
charge records are processed. 


In the next program cycle, RPG II logic determines which 
record to process next. If there is a charge record in the 
primary file, this record is selected since its match field is 
the same as the match field on the previously processed 
record. 


When a charge record (record type 02) is selected, the first 
step is to determine if the charge is to be discounted. Ifa 
discount record was processed for this customer, indicator 
22 is still on. Thus, the calculations on lines 10-11 are per- 
formed only if 22 is on. The charge, whether discounted or 
not, is then added to the previous balance to accumulate a 
new balance (line 13). The individual charge is then printed 
and any remaining charge records are processed in the same 
way. 


When all charge records for this match group are processed, 
a name and address record for the next customer is available 
in the primary file, while his balance record is in the sec- 
ondary file. As before, since both records match, RPG II 
logic selects the primary file name record to process first. 


Referring to the input specifications for this program, the 
customer number field on the name record was assigned as a 
control field, as well as a match field (see Figure 7-17). 
Since the customer number on the name record just selected 
differs from that on the previous name record, a control 
break occurs. Before processing the name record for the sec- 
ond customer, then, total operations for the previous group 
are performed. Thus, the output specifications in Figure 
7-19, line 13, cause the new balance (which has been ac- 
cumulating for every charge record processed) to be printed 
on the customer’s bill.. 
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Effect of Forcing on the MR Indicator 


In this last example, we assumed that for every customer, 
there is at least one record in the primary file (name record) 
and one record in the secondary file (balance record). For 
every record processed then, there exists a matching record 
in the other file. 


Although a matching record condition actually exists for all 
records, the MR indicator is not necessarily turned on for 
every record. When RPG II logic selects records in the usual 
order, the MR indicator is on during the processing of these 
records. However, MR is never turned on for a record which 
is forced. If a file is to be forced, the RPG II logic doesn’t 
even compare the two files and, thus, doesn’t determine if a 
matching record condition exists. A forced record is proc- 
essed, then, as if it contained no match fields. 


The last example did not require that any calculations or 


~ output be conditioned on the basis of matching records. 


Nevertheless, you must be aware of the effect forcing has . 
on the MR indicator so you won't incorrectly think MR is 
on when it is actually off. 


PROCESSING DEMAND FILES (READ OPERATION) 


Using the FORCE operation, you can override normal RPG 
I1 logic for selecting records on the next program cycle. 
Suppose, however, you want to select records to be proc- 
essed during the current program cycle. For example, a 


company maintains a file of employee numbers, NUMBRFLE. 


Each number is on a separate record (Figure 7-20). Those 
records containing numbers that are already assigned to em- 
ployees are identified by a flag (character X in position 8 of 
the record). If the number has not been assigned to an em- 
ployee, the record does not have a flag. 


For each record that is read from the file of new employee 
records, NEWNAME (Figure 7-20), one or more records 
must be read from NUMBRELE to find a number that can 
be assigned to the new employee. The new number must 


.be found during the current cycle, since the new employee 


record is added to the employee master file, NAMEFILE 
(Figure 7-20), after a number is assigned. 
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Figure 7-20. Using the READ Operation and a Demand File to Assign Man Numbers to New Employees 
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By designating NUMBRFELE as a demand file (Figure 7-21, 
insert A) you can request input from the file as many times 
as necessary during a single program cycle. In order to re- 
quest input, you must use the READ operation code in the 
calculation portion of your program (Figure 7-21, insert C). 
Each time a READ operation is done, a record is read from 
NUMBREFELE. 


It is possible that end of file for the demand file could be 
reached during a program cycle. Two options are available 
to handle this situation. In the example (Figure 7-21, insert 
C), an indicator has been entered in columns 58-59. An in- 
dicator specified in columns 58-59 of the specification line 


containing the READ operation will turn on after each 
READ operation if an end of file condjtion is reached. In 
the example, new employee records are listed on the printer 
as they are added to NAMEFILE. If end of file is reached 
on NUMBRELE before numbers have been assigned to all 
new employees, indicator 77 is turned on and the new em- 
ployee records to which numbers have not been assigned 
are listed with an appropriate identification. 


a 
t 


If an end of file indicator is not entered in columns 58-59, 


_ the program will halt when end of file is reached on the de- 


mand file and each time READ is executed thereafter. 
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Figure 7-21 (Part 2 of 2). Coding to Use a Demand File to Assign Man Numbers to New Employees . 
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Considerations for Using READ and Demand Files 
The following files can appear as Factor 2 ina READ opera- 
tion (all must be designated demand files with a D in col- 


umn 16 of the File Description sheet): 


1. Sequential disk files processed consecutively and 
specified as input or update files. 


2. Indexed disk files processed sequentially by key and 
specified as input or update files. 


3. Indexed disk files processed sequentially within 
limits and specified as input or update files. 


4. Direct disk files processed consecutively as input or up- 
date files. 


5. Console and CRT files specified as input files. 

6. Card files specified as input or combined files. 

7d: Ledger card files specified as input or combined files. 
8. Data recorder files specified as input files. 

9. Tape input files. 


10. SIOC input and update files (SPECIAL device). 


11. Teleprocessing input and combined files (BSCA device). 


12. Device independent input files. 


When using the READ operation for demand files remem- 
ber: 


1. Demand files (except those assigned to the Model 6 
KEYBORD) can only be processed by the READ 
operation. 


2. Control levels, matching fields, and look-ahead fields 
are not allowed with demand files... 


3. Numeric sequence testing on the Input sheet is not 
allowed for demand files. 


4. The MR indicator may not be entered in columns 
63-64 (Field Record Relation) on the Input sheet. 


5. When a demand file is conditioned by a U1-U8 indi- 
cator which is not on, no records will be read from 
that file and the end-of-file indicator in columns 
58-59 will not turn on. 
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6. | When reading from several demand files during the 
same RPG II cycle, record identifying indicators as- . 
signed to the demand files will remain on throughout 
the cycle if the previous READ operations were 
executed successfully. . 


REPETITIVE OUTPUT (EXCPT OPERATION) 


RPG II has a special operation code called EXCPT which 
allows you to write or punch as many records as are re- 
quired during one program cycle. 


Normally a record is written or punched at either detail or 
total output time. Using EXCPT, records can be put out 
during detail or total ca/cu/ation time. Each time you use 
the operation code EXCPT, specified records are written 
immediately. For example, if you use eight EXCPT opera- 
tion codes in succession, you can get an exception output 
cycle eight times. The records are identical if the data fields 
in the exception records are not altered between the EXCPT 
operation codes on the Calculation sheet. 


When you use the EXCPT operation code, you also must 
specify which records are to be put out during calculation 
time. These records are identified by an & in column 15 of 
the Output-Format sheet. Only those output lines identi- 
fied by an E will be put out during an exception output 
cycle. | Pe 


~ Using EXCPT and *PLACE 


The reserved word *PLACE duplicates fields and places 
them on the same line. In the discussion of *PLACE in 
Chapter 3, an example is used in which three mailing labels 
were printed for each customer using “PLACE. If you 
wanted to print 15 labels for each customer, however, you 
could not use only the reserved word “PLACE. The only 
way would be to print the same three mailing labels five 
times in succession. 


In the RPG II program cycle, each record specified is written 
or punched only once per cycle. For each record read by 

the program shown in Figure 7-22, the detail line specified in 
lines 01-04 is written only once. Remember that the ~*PLACE 


_ entry causes the field to be duplicated. Using *PLACE 


one line is printed with three identical names. The same is 
true for each of the other records specified. If you want to 
print 15 identical mailing labels, you need all records printed 
five times each. 
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Figure 7-23. EXCPT Operation Code Used with Exception Records 
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Figure 7-23 shows the specifications necessary to print 15 
mailing labels per customer. The *PLACE specifications on 
the Output-Format sheet will cause three mailing labels to be 
) printed side by side on the paper. Each EXCPT code used 
on the Calculation sheet causes all records identified by an 
E in column 15 of the Output-Format sheet to be printed 
one time in the order shown on the sheet. Because all four 
lines are to be printed on the mailing label, al! are identified 
by an E. The five EXCPT codes will cause five rows of three 
mailing labels each to be printed. 


Another set will not be printed at detail output time, be- 
cause all records having an & in column 15 can be printed 
only at calculation time when the EXCPT operation code 
is encountered. 


EXCPT can be used with punched cards or disk as well as 
printed output. It operates in the same way in all cases. 
Each time the EXCPT code is encountered, output lines 
identified by an E in column 15 are executed. 


Only output files may have EXCPT records specified; 
EXCPT cannot be used for combined files. 


Me 


Conditioning the Use of EXCPT Operation 


There are two ways you can condition an EXCPT opera- 
tion: (1) on the Calculation sheet; and (2) on the Output- 
Format sheet. 


The EXCPT operation can be conditioned on the Calcula- 
tion sheet in the same way as any other operation. As 
shown in Figure 7-24, the EXCPT bacords. are put out only 
when MR is on. 


An indicator used on the Calculation sheet controls the 
printing or punching of all EXCPT records. Individual 
EXCPT records are controlled by indicators specified in 
columns 23-31 of the Output-Format sheet. These indica- 
tors are used in the same way for EXCPT records as they 
are for all other records. oe 


Restriction: Overflow indicators cannot.be used to condi- 
tion an EXCPT line. This means that an EXCPT record ~ 
cannot be a record that is printed only when the end of the 
page has been reached. . 


Remember, these lines are exceptions. They print only at 
calculation time, not at output time. Therefore, they could 


‘not possibly be printed when other overflow lines are. 


An EXCPT line may be, however, printed on the overflow 
line. If it is, the overflow indicator will be turned on as 
usual. EXCPT lines can even fetch overflow. You may 
place an F in column 16 of any exception line. If the over- 
flow indicator is on when the EXCPT line having an F in 
column 16 is reached, all lines conditioned by the overflow 
indicator will be printed before the exception line is printed. 
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Figure 7-24. Conditioning the EXCPT Operation Code 
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Review 7: 


FORCE 


1. What processing situations would require you to alter normal RPG I! multifile logic 
by using the FORCE operation? 


2; What two considerations are necessary to determine how the order of processing 
must be altered in a program? 


3. Describe what occurs when a FORCE operation is performed. 


4. |Acommission report is to be prepared listing each salesman and his commission 
amount. For each salesman record (MASTER file), there are seven commission 
records (COMMIS file). The records are described as follows: 
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a. Are the following calculation specifications correct for the required order of file 
processing? 
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b. On what condition will a record from MASTER be processed? 

c. On what condition will a record from COMMIS be processed? 

d. What specification changes must be made to process seven COMMIS records 
following each MASTER record? 

e. Is FORCE necessary to process the records? Why? 


5. Consider again the MASTER and COMMIS files as described in question 4, without 
match fields. However, assume that, for every MASTER record, there may be any 
number of related COMMIS records. 

Using look-ahead fields and FORCE, code the necessary input and calculation 
specifications for determining the proper order of file processing. Compare the 


number of specifications to the number required if the files were processed by 
matching record logic. 


READ 


6. List four ways in which a demand file differs from an ordinary secondary file. 
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EXCPT 
7. What occurs when the EXCPT operation code is executed? 


8. In a program, you need to punch a specified number of cards for each item. This 
number will be punched in each input card. Refer to the coded Input sheet for 
record layouts and code the Calculation and Output-Format sheets for the program. 


Printed 
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Answers To Review 7 


Match fields cannot be assigned to the files and you need to: 
@ Alternate processing between two files. 


@ Process a primary file record followed by a number of secondary file records. 


-@ Process a secondary file record only when it matches a primary file record. 


1 a. 
b 
2. a 
b 


. Match fields are assigned to both files and you need to alter the order of match- 


ing record logic to process a primary file record, then matching secondary file” 
records before matching primary file records. 


. When ech file must be processed and under which conditions. 
. Whether RPG I! logic would select the appropriate record or if the file must be 


forced. 


3. No action occurs at the time the specification is performed. At the beginning of the 
next program cycle, the next record from the file specified as Factor 2 of the _ 
FORCE operation is selected (by being forced) for processing. 


. No, the specifications are incorrect. 
. AMASTER record will be processed in every program cycle until end of file j is 


reached. 
A COMMIS record will not be processed until all records in the MASTER file 
have been processed. 


. Lines 05 and 06 should not be conditioned by record idaniitying indicator 07. 


_ The COMP operation should be performed for every record type to determine if 
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the FORCE is to be performed. It may be necessary to force a COMMIS record 
following either a MASTER record or another COMMIS record. For this reason, 
you must be able to perform the FORCE operation while processing either of 
the record types. 


. The FORCE operation is not necessary. The RPG II logic of matching records 


can determine the proper order of processing if the SLSNBR fields on each 
record type are assigned as match fields on the Input sheet. 


5. Input specifications to define look-ahead field: 
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) Calculation specifications to determine order of file processing: 
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If match field entries had been assigned to the SLSNBR fields on the Input sheet, 
input specification lines 10 and 11 would not be necessary to define the look-ahead 
field. No calculation specifications would be required to determine the order of 
processing, 


6. a. -A demand file is processed only by the READ operation code during calculations. 
Demand file records are never selected by normal RPG I! multifile logic. 

b. Match fields cannot be assigned to a demand file. 

c. Look-ahead fields cannot be defined for a demand file. 

d. Reading an end of file record (/*) from a demand file does not set the LR 
indicator on. Instead, an end of file indicator can be entered in columns 58-59 
of the READ specification line. This indicator will turn on each time a READ 
is executed which encounters an end of file condition in the demand file. 


7. Immediate output for specified records occurs. These records are coded as excep- 
tion records by an E in column 15 of the Output-Format sheet. 


8. See Specification sheets. | 
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Chapter 8. Tables 


CHAPTER 8 DESCRIBES: 
Uses for tables. 
RPG II coding used to search tables. 
Davignita ‘ble input aide 
. LOKUP operation code. 


Use of table data in calculations and output operations. 


BEFORE READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
RPG II object cycle. 
Matching records processing. 


Use of indicators to condition operations. 


“AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO: 

State uses for tables. | 
Define a gee on the Extension sheet. 
Code problems using a single table. 

_ Code problems using related tables. 
Define and code the LOKUP operation code with tables. 
Describe data and store it in a table. 
Note: You can use the review questions contained in Review 8 at the end of this 


chapter to test your comprehension of the chapter. Answers follow the review. - 
questions. | - ; 


Tables 8-1 


INTRODUCTION 


If you wish to make a telephone call to.a person, you must 
first determine his telephone number. Imagine trying to ob- 
tain the number if no telephone directories were available! 
For such reasons, similar items of information are grouped 
and organized so they can be referenced easily and quickly. 


A table is a collection of related data organized in such a 
way that each item of information can be referenced by its 
position within the table. A telephone directory consists of 
two tables of information: a name'list arranged alphabeti: 
cally and a number list arranged in no apparent order. Each 
telephone number, however, occupies a position in the num- 
ber list corresponding to the position of a particular name in 
the name list. . . oo 


Each item within a table is called a table element. Thus, 
each name would be an element of the name table, while - 


each number would be an element of the telephone number — 


table. Ce rer 


If you wished to determine Ken Adams’ telephone number, 
you would look through the list of names to locate KEN 
ADAMS. This procedure of checking the elements of a -— - 


table one at a time to find a particular entry is called search- © 


ing a table. Before looking through the name list,-you must 
know what information you wish to find, the name KEN 
ADAMS. This data is referred to as the search word. " “ 


As shown in Figure 8-1, the name list is searched to find 
an entry which is equal to the search word. The matching 
entry, KEN ADAMS, is found in the third element of the 
name table. His corresponding telephone number, then, is 
found by selecting the third element in the number table. 


When two related tables are used, as in a telephone direc- 
tory, actually only one table is searched (name table). When 
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the search condition (in this case, an equal match) has been - - 


satisfied, the data in the corresponding element of the sec- 
ond table becomes available. Thus, the first table is used as 
a means of locating data in the second table. 


-A telephone directory is an example of tables which organ- 
ize information that we must reference over and over again 
in our every day lives. Likewise, tables can be used to or- 
ganize data which must be referenced repeatedly in your 
data processing jobs. 


Search Word 


ADAMS KEN [| 7° 


NAME Table 





"NUMBER Table 







en ee , oN, 






ABRAMS JOHN - . + -\. 286-6424 





ACKERMAN GAIL -.~ 289-2933 








. . . 938-7515 > 








ADAMS KEN 


ANDERSON THOMASE. . ; . 935-8381. 





BABITT ROBERTA- « + + + + 288-7587 





BARSNESS RICHARD. - 938-3932 









WIK GAIL . 2... ee es 288-4663 


Figure 8-1. Searching a Table 


Let’s assume that customers have purchased various items 


from a company sales.catalog. The sales file (Figure 8-2) 
would contain records showing the customer's account num- 
ber (CUSTMR), the item ordered (ITMORD), identified by 
a code, and how many were ordered by that customer 


- (QTYORD). 


Furthermore, the company keeps.an inventory file (Figure 
8-2) to contain data about each item which is carried in 
stock. A separate record is kept for each item showing the 
item code. (ITEM), the quantity on hand (QTYSTK), and 
the unit cost of each item (COST). 


Before you can ship the customer’s orders, you must first 
determine if the item ordered is still carried in stock. To do 
this, a clerk could spend time looking up each item ordered 
to see if that item is recorded in the inventory file. How- 
ever, the same item will probably be ordered by many cus- 
tomers. Thus, the same inventory file records would have 
to be referenced over and over again. 


\ 


SALES File 


Record 


‘ [ssse7eene7 15 
. [s27sestces 27 


3 $346724C89 63 


1.2 3 4 5 67,6 9 10 ft 12 13.14.15 16 17 18° 19 20 


4 $569823B83 37 


9 10. TH 12 13,14 15 16 t? 18 19 20, 


CUSTMR | QTYORD 


ITMORD 


Figure 8-2. Data for Determining if Orders Can be Filled 


INVNTRY File: 






A23 33 140 













66 °° «25. 


5S 6 7 B 9,10 10 12813 te ets 16 17 18 19 20 


B21 -§8 16123 


S$ 6 7 @ 9.10 Ih 12013 1418 16 17 18 19 20 






B83 46 «09 


1.23 4.5 6 7 & 9710 1H 12G13 14 15 16 17 1B 19 20 


04611017 ‘oo, . 


10 19 12943 16 98 16 17 18 19 20 
' : 


{5 1 18 16 17 18 19 20 









70 21'50 


S 6 7 8 8 tO 12913 4 15 16 17 1B IS 20 





c89 25600 110 
$ 2 a4 $ 6 2. ses OT 2g 4 1S % 17 ee 
item.-| ~~ cost 
QTYSTK 


£18) 2345678 90n 1Zg!3 4,15 16 17 18 19 200. 


Tables 
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Searching a Single Table 


RPG I! can search for the data in much less time by per- 
forming a table lookup function. As shown in Figure 8-3, | 
a table (TABITM) would be set up.in storage to contain ali 
of the items available (see Loading. Tables i in this chapter 
for methods of loading table data into storage). 


The second field of each sales fiooed tells the program 
which item to /ook up. For every sales record read into the 
computer, TABITM is checked to see if the search word 
(item code on the sales record) matches an entry in the 
table. 


In addition to searching for data quickly, use of the table ; 
lookup can often reduce the number of RPG II specifica- _ 
tions needed in a program. All you must do is set up and 
define the table, and specify that the eIgekup operation is . 
to be perrormed’ 


.. -TABITM 


Search 
Word 





$275631C65. 2:7 


123456789 0n 2113 14 15 16 17 18 19 20 


CUSTMR ITMORD QTYORD 


SALES record 


Figure 8-3. Searching a Table for a Particular Data Item 
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Data used to create a table must be obtained from table in- 
' put records. These records can be taken from the keyboard 


Designing Table Input Records 


or CRT, punched cards, magnetic tape, or disk. The records 
are read by the computer and entries are placed side by side 


_ in storage to form the table. 


The inventory file for this company indicates that 98 types 
of items are carried in-stock.: Therefore, the 98 item codes 


’ must be contained in table input records to provide the en- 


tries for TABITM. 


Number of Table Input Records Required for a Table 


How many records would be necessary to punch the 98 
item codes? That is entirely up to you. The number of 
records required to contain the table data depends on the 
number of entries you want on each record. 


Number of Entries on a Table Input Record 


Table input records may either contain one entry or a num- 

ber of entries. The point to remember is that all table input 
records for a single table must contain the same number of 
entries, except for the last record. ee 


~ The use of one entry per record is very convenient if it is 


necessary that the entries be in a particular order. Then to 
add or delete entries, you merely add or remove a record. 
Otherwise, you would have to recreate all of the records 
from the point of change to the end of the table. However, 
in the TABITM table, item code entries need not be in order, 
so including a ‘number of entries in each record reduces the 
number of records required. 


For TABITM, 98 entries must be recorded on table input 
records. If 96-column cards are used, 32 entries fit on each 
record, since each item code is three characters long. There- 
fore, to save card space, you could punch three table input 
records containing 32 entries each and a fourth table input 
record for the remaining two entries. (See Figure 8-4.) In 
this way, all records contain the same number of entries 
except the last record. _ 


Of course, you do not have to fill the entire record with en- 
tries, as we have done. For instance, you may want the last 
36 columns of a card to contain no punches. In that case, 
you could punch 20 entries (card columns 1-60) into each 
of four table input records. The remaining 18 entries could 
then be punched into a fifth record. 


Notice in Figure 8-4 that the two entries in the fourth table 
input record are placed side by side. Since there are unused 


Record 4 card columns on the record, why not space the entries? 
Contains You cannot, because all entries must be continuous on the 
2 Table record, with no blank columns between entries. Further- 
Entries more, the first entry on each record must begin in position 


one. 





Describing Table Input Records with Extension Specifica- 
tions 


Once the table input records have been designed, you then 


Records 

1.2 and3 describe them to the RPG I! Compiler program. Ordinarily, 
Each Contain the data . input eee : described AACE aie 
32 Table A 231A 87182118 831C 46 } tions ont e Input sheet. owever, you escri et oe ata 
Entries on table input records by coding extension specifications 


on the upper half of the Extension and Line Counter sheet. 
(Hereafter, we will refer to the upper portion of the form 
as the Extension sheet and the lower portion as the Line 
Counter sheet.) 


Figure 8-5 shows the extension specifications needed to de- 
scribe the table containing item codes. As you can see, a 
single table can be described using only columns 27-45. Of 
course, remember that the page and line number (columns 
1-5) and form type (E in column 6) are also part of the en- 
tire specification line. 





Figure 8-4. Four Table-Input Records for TABITM Entries 


RPG EXTENSION AND LINE COUNTER SPECIFICATIONS Sue 
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Extension Specifications 


Record Sequence of the Chaining File 


Number of the Chaining Field Table or 


To Filename Table or ; f j Array Name ; Comments 
Array Name |? (Alternating 


From Filename _ i Format) 


Form Type 





~~ 


) Figure 8-5. Describing Table-Input Records 


Tables 98-5 


The extension specifications provide the following informa: 
tion about each table to be used: 


1. Name of each table (columns 27-32). 
2. Number of table entries per table input record (col- 


umns 33-35). 
3. Number of table entries per table (columns 36-39). 
4. Length of each entry (columns 40-42). 


5. Whether packed or binary data is contained in the 
table (column 43). 


6. Number of decimal positions in ‘each numeric entry, 
(column 44). 
7. Sequence of table entries, if any (column 45). 


Each type of entry will be discussed in turn. From File- 
name (columns 11-18), To Filename (columns 19-26), and 


the entries in columns 46-57 are described later in this chap- 


ter. 


Assigning Table Names 


Every table used in a program must be assigned a name 
from three to six characters long. The table name may con- 
tain any combination of alphabetic characters and numbers. 
However, the first three characters of the name must be 
TAB. 


With these points in mind, which of the following table 
names are not acceptable and why? 


TABA 15ABCD 


TAB C TABSTATE 


TB123 *TAB 
TAB$2 


TAB C and *TAB are not acceptable, as table names cannot 
contain blanks or special characters, such as the *. TAB$2, 
on the other hand, is an acceptable table name, since $ is 
one of the three special characters which can be considered 
an alphabetic character. (The other two are # and @.) 


The names 15ABCD and TB123 are invalid because they 
do not begin with the alphabetic characters TAB. Since 
TABSTATE contains more than six characters, it cannot 
be an acceptable table name. TABA and TAB$2 are the 
only two valid table names shown. 
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If possible, it is helpful to assign table names which are 
meaningful. For this example, the name TABITM has 
been assigned. Such a name gives an indication of what - 
kind of data is contained in the table (in this case, item 
codes). - 


When a single table is being used, as in this case, the table 


name is entered in positions 27-32 of the Extension sheet 


(see Figure 8-5). 


Number of Table Entries per Table Input Record 


The number of entries in each table input record is speci- 
fied in columns 33-35. Figure 8-5 shows 32 entries per rec- 
ord for TABITM. In this way, the compiler. program will 
expect all table input records to contain 32 entries, except 
the last record which may have fewer entries. Notice that 


‘the number entered in these columns should end in column 


35. 


Number of Table Entries Per Table 


The number of entries which can be contained in the entire 
table is entered in columns 36-39 of the Extension sheet. 

As shown in Figure 8-5, the number -e for TAB should 
end in column 39. 


Length of an Entry 


The length of each table entry is indicated in columns 40-42, 
with the number ending in column 42. Numeric table en- 
tries may be up to 15 digits long, while alphameric entries 
can be as long as the maximum record length for the device 


_ (256 maximum). 


For TABITM, the length 3 has been entered. It is possible 
to specify only one length. Therefore, this necessarily means 
that all entries in a table must be the same length. 


At this point, you may be wondering what to do if all en- 
tries are not the same length. For instance, you might wish 


_ to make a table containing the months of the year. The 


solution is simple — all entries are made .to be the length of - 


_ the longest entry. The word SEPTEMBER contains the — 


most characters. Therefore, each entry should be 9 charac- 
ters long. To make JUNE an entry with length of 9, you - 
would place 5 blanks after the letter E (see Figure 8-6). In- 
serting extra blanks to lengthen the data entry is referred to — 
as padding with blanks. If your table entries were numbers, 
instead of letters, you would pad the short entries with 
zeros or blanks. (For numeric entries, the zeros or blanks a 
would probably be placed in front of the number.) \ 


Entries with Decimal Positions 


When the entries of a table are numeric, it is necessary to 
specify in column 44 the number of decimal positions (0-9) 
in each entry. Even if a numeric entry contains no decimal 
positions, a O must still be entered to indicate numeric data. 
When decimal positions are not specified (column 44 left 
blank, as in Figure 8-5), RPG II considers the table entries 
to be alphameric. 


Sequence of Table Entries 


b 
6 
b 
b 
b 
i) 
b 
b 


For TABITM, the item codes need not be in any particular 

~<—— Longest Table Entry order. Thus, column 45 is left blank in Figure 8-5. How- 
ever, if the table entries are in ascending or descending 
order, an A or a D is entered under Table Sequence (column 
45). Note that if a table is to be in sequence the entry is 
made on the Extension sheet. For input files, other than 
table files, the sequence entry is always made on the File 
Description sheet. 


r or of FB 





Table Of Months 
Coding the Table Lookup Operation (LOKUP) 


Fighre' 6:6. Making Table Entries the:Same Length Once the table input records have been described, you tell _ 


RPG II to search the table by coding the LOKUP operation 


7 on the Calculations sheet. This involves specifying: 
) Padding a table entry with blanks should not be confused 

with spacing entries on a record. .As mentioned, no blanks 1. The LOKUP operation code. 

can occur between entries. However, blanks can be part of . 

an entry in order to make all entries the same length. 2. The name of the table to be searched. 


3. The data which is being searched for. 
Packed or Binary Table Data (Systems with Disk Storage) 
4. Conditions which must be satisfied for a successful 
An entry must be made in column 43 if the data for a pre- search. 
execution time table is in packed decimal (P) or binary (B) 
format on disk or tape or in packed format on 80-column 
cards (not allowed on 96-column cards). This entry applies 
only to numeric tables. For numeric tables in packed deci- 
mal format, the unpacked decimal length of the entries 
must be entered in columns 40-42 (Length of Entry). For 
numeric tables in binary format, enter the number of bytes 
required in storage for the binary field. For a two-position 
binary field, the entry in columns 40-42 is 4; for a four- 
position binary field, the entry is 9. 
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As shown in Figure 8-7, the operation code LOKUP is en- 
tered in columns 28-32 of the Calculations sheet. This 
operation code causes a search to be made for a particular 
item in the table named in Factor 2. Thus the name of the 
table being searched, TABITM, is entered under Factor 2 
(columns 33-42), beginning in column 33. Remember that 
the table being searched must have been previously de- 
scribed on the Extension sheet. _ | 


Factor 1 (columns 18-27) contains the field name of the 
data which is used for comparison during the table search. 
In this case, the second field of the sales record (called 
ITMORD) contains the code for the item ordered (the 
search data). Thus, 1TMORD is entered, beginning in col- 
umn 18. , 


The fields on each SALES record have been described on 
the Input sheet. The field (ITMORD) which contains the 
search data must liave been described so that it agrees with 
the way the table entries have been described. That is, the 
search data and the table entries must have the same length, 
the same number of decimal positions, and the same format 
(alphameric or numeric). As shown in Figure 8-8, both 
ITMORD and the table entries are defined as three charac- 


ters long and as alphameric (no decimal positions specified). 


In this case, the item which is being searched for must be 
an exact match of the search data. This is referred to as 
searching for an equal condition only. The lookup pro- 
cedure would begin at the first element of TABITM and 
continue, one element at a time, until an equal entry is 
found. For this reason, it isn’t necessary that the table 
elements be in any particular order when searching for an 
equal condition, ; 
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Of course, if the item searched for is not found after check- 
ing all elements of TABITM, the company does not carry’ 
that item in stock. Thus, the equal condition must be satis- 
fied if this search is to be successful. 


But, how will you know if the search was successful? To 

determine this, you must know if an equal match was found 
or not. Thus, you should assign a resulting indicator for the 
lookup which will turn on if (and when) the equal condition 
is satisifed. , | | 


As shown in Figure 8-7, the indicator 05 is assigned by en- 
tering 05 on the Calculation sheet under Lookup Equal 
(columns 58-59). If an entry cannot be found in the table 
to correspond to the search data, the 05 indicator will turn 
off, 


TWO TABLE SEARCH 


As you have seen, a single table can be searched merely to 
see if certain information (an item code) is in the table. 
However, usually you will want to do more than this. For 
example, when the orders are shipped, you will also want 
to send bills to each customer for the amount of the order. 
Before RPG {I can print the bills, it must calculate the 
amount each customer owes. To do this, the unit cost of 
each item must be determined. The unit cost of an item is 
then multiplied by the number ordered to give the total 
amount due from a customer for that type of item. 
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Figure 8-7. Specifying a Single-Table Search 
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igure 8-8. Specifying the Same Length for Search Word and Table Entry 
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At this point, you have already created a table (TABITM) 
listing the codes of all items the company sells. The unit 
cost for each item (a 5-digit field on each inventory file 
record) can be stored in a second table, called TABCST. 
This table should be organized such that the position of a 
cost within TABCST corresponds to the position of its re- 
lated item code in TABITM (Figure 8-9). 


INVNTRY 
file 





ITEM OQTYSTK COST 


00140 
00025 


01623 


38 
item 
wo codes 
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TABITM _ TABCST _ 


Figure 8-9. Creating Two Related Tables 
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unit costs. 


Let's take a look at one of the records in the SALES file. 
(Figure 8-10) and see how the two tables can be used in ye 
determining the appropriate cost for the item ordered. \ 
The procedure is much the same as the way you located 
Ken Adams’ telephone number in the telephone directory. 


SALES record 







569823 


ITMORD QTYORD 








Search Word 





ITMORD 





TABITM . TABCST 
Me 


Figure 8-10. Performing a Two-Table Search 


First, TABITM is searched to find the table element which 
contains the same item code as the search word (B83) on 
the SALES record. If no match is found, that SALES rec- 
ord can be selected into a special stacker so the customers 
can be notified of the orders which can’t be filled. How- 
ever, in this case, the equal entry is found in the fourth 
element of TABITM. The entries in TABCST were organ- 
ized to correspond with entries in TABITM. Therefore, the 
fourth element of TABCST contains the unit cost for the 
search word. The program can then use the information 
referenced (unit cost) to calculate the amount to be billed. 


When two related tables are used, as in this example, actu- 
ally only one table is searched. When the search condition 
(in this case, an equal match) has been satisfied, the data in 
the corresponding position or element of the second table 
(related table) becomes available. Thus, the first table is 
used as a means of locating data in the second table. Ina 
telephone directory, a person’s name is used as a means of 
locating his telephone number. 


Designing Table Input Records for Two Tables 


Records With Entries For Only One Table 


In designing the table input records for TABITM, you were 
concerned only with entries for a single table. Thus, four 
table input records were created to contain only item codes. 


Another set of table input records could be created to con- 
tain the 98 unit cost entries for TABCST. Each unit cost 
entry (from the inventory records) requires five columns 
(three digits for dollars, two digits for cents). Again, it is 
up to you to determine how many records you wish to use 
and the number of entries to be contained in each record. 
For example, let’s say that 18 entries (columns 1-90) are 
punched into each of five table input cards and the remain- 
ing eight entries are punched into columns 1-20 of a sixth 
card. 


As shown in Figure 8-11, you would then have two separate 
table input files: records for TABITM containing only item 
codes and TABCST records containing only unit cost 
amounts. 





2 Item Code Entries 


32 Item Code Entries 


32 Item Code Entries 


32 Item Code Entries 


Table-Input File 
for TABITM 


(4 records) 


8 Unit Cost Entries 
18 Unit Cost Entries 
18 Unit Cost Entries 
18 Unit Cost Entries 
18 Unit Cost Entries 
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Table-Input File 
for TABCST 


(6 records) 


Figure 8-11. Separate Records for Each Table 
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Records With Entries For Two Tables 


Another method of designing table input records allows you 
to use only one table input file for both tables. This may 
save input record space and will usually reduce the number 
of RPG II specifications needed to describe the table input 
records, Entries from the first table are alternated with 
‘entries from the second table (Figure 8-12). The records 

are then referred to as alternating format table input records. 


As you can see, a table input record can begin (position 1) 
with an entry from either the first table or the second table. 
However, if you decide to use the alternating format, every 
record in the table input file must begin with the same type 
of table entry (table 1 or table 2). 


The number of entries that you put on an alternating for- 
mat, table input record is still up to you. If you wish, a 
single record can contain one code for TABITM and one 
unit cost from TABCST. Or, the record may contain as 
many pairs of related entries as possible. In this case, all 
records, except the last, must contain the same number of 
entries. 


Every record in file ITEM Cost ITEM COST 


begins with entry 
for the same table 
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Single Table - Input File. 
Entries for TABITM and 
TABCST in Alternating 
Format. 


Figure 8-12. Alternating-Format Table-Input Records 
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ITEM | COST]! TEM] COST] ITEM} COST} ITEM! COST 


ITEM [cost] ren cosr| ITEM | cost] rem COST 
iM cOs | ITEM [cost] rem] cost] ITEM | COST 





For TABITM and TABCST, each pair of related entries will 
require eight card columns. By punching 12 pairs of entries 
in a record, an entire card can be filled. Thus a table input 
file to contain all entries (98 pairs) from both tables can 
consist of nine alternating format, table input cards. The 
first eight records might each contain 12 pairs of entries 
and the last record might contain two pairs of entries. 


4 


As mentioned before, entries for TABITM are each 3-char- 
acter alphameric data. For TABCST, 5-digit numeric en- 
tries are needed. All of the entries for a single table must 
be alike; that is, all alphameric or all numeric. However, 
the entries. for. an alphameric table and the entries for a 
numeric table can both be on the same table input record 
when an alternating format is used. , 


Although each table input record contains entries from both 
tables, actually two separate tables are created in storage 
from these records. The RPG II Compiler knows that two 
tables are to be set up, rather than a single table, because of 
the way the records are described on the Extension sheet. 


‘Last record contains 
two pairs of entries 


NY 
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Describing Two Tables with Extension Specifications 


When two related tables are used in a program, you have the 
choice of designing two table input files (one for each table) 
or only one table input file consisting of alternating format 
table input records. 


If you decided to set up TABITM and TABCST using sep- 
arate files, as discussed earlier, the two tables would be de- 
scribed as shown in Figure 8-13. Since each table has its 
own set of input records, a separate line of extension speci- 
fications is needed for each table. 


Now take a look at Figure 8-14 which describes the same 
two tables. Notice that only one-extension line is coded 
when alternating format, table input records are used. 
Since one line is coded for each set of input records, the 
second table of the alternating format record must be en-: 
tered on the same extension line as the first table. 


Remember that two separate tables are created, even if you 
use alternating format records. Therefore, both tables must 
have unique names, which are specified on the Extension 
sheet. The table whose entry appears first on a table input 
record is named in columns 27-32. The name of the alter- 
nating table (in this case, TABCST) is entered in columns 
46-51 of the same line. The alternating table is always the 
table whose entry is the second one in a pair of related en- 
tries. 


Notice that Number of Entries Per Record (columns 33-35) 
and Number of Entries Per Table or Array (columns 36-39) 
do not have corresponding specification columns for alter- 
nating tables. Since the number of entries per record and 
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Figure 8-13. Describing Separate Table-Input Records 


number of entries per table must.be the same for each of. - 
the alternating tables, separate specifications are not needed 
for the second table. 


However, the Length of Table Entry (columns 52-54) must 
be indicated since it may be different for the two tables. 


In Figure 8-14, a 3 has been entered in columns 40-42 as 
the table entry length for TABITM, while a 5 has been en- 
tered in columns 52-54 specifying the length of the unit 
cost entries for TABCST. 


The unit cost entries for TABCST are in the form of 12467, 
which would represent $124.67. Therefore, a 2 has been 
entered for the number of decimal positions (column 56). 
This specification indicates that the entry is numeric and 
contains two decimal positions.: . | 
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The table entries for TABCST are not in any special alpha- 
betic or numeric order which the RPG |! Compiler program 
could check for accuracy. Thus, no table sequence is speci- 
fied for TABCST (column 57 is left blank). Likewise, tele- 
phone numbers in a directory are not in sequence. However, 
just as phone numbers are arranged to correspond with re- 
lated names, the TABCST entries have been arranged so a 
particular unit cost corresponds with its related item code. 


Coding the Table Lookup Operation (LOKUP) 


Now that both tables have been set up, TABITM is to be 
searched to find the table element which contains the same 
item code as the code (search word) on the SALES record. 
This simple lookup procedure is coded with the same cal- 
culation specifications as you used before (Figure 8-15). 
The field name or literal constant which contains the search 
code is entered under Factor 1 (ITMORD), the LOKUP 
operation is specified in columns 28-32, and the name of 
the table being searched (TABITM) is entered under Factor 
2. If an equal match is found in searching the table, result- 
ing indicator 05 will be turned on, as specified in columns 
58-59. 


However, you want to do more than just see if the item 
ordered is carried in. stock. If the search is successful, you 
also want to determine the appropriate unit cost for the 
ordered item. 


To reference the second table (TABCST), additional speci- 
.fications must be entered on the same line of the Calcula- 
tion sheet. As Figure 8-15 shows, the name of the table 
(TABCST) from which you wish data to be made available 
is entered as the Result Field (columns 43-48). If (and 
when) the equal search is satisfied, the corresponding data 
looked-up in TABCST will be made available. 





Field length and decimal positions have not been entered in 
columns 49-52. These specifications are not required since ff 
the table named under Result Field (TABCST) was previous- . 
ly described on the Extension sheet. However, if you want 

to enter these specifications again on the Calculation sheet, 

the numbers must agree with those in the extension specifi- 
cations. For TABCST, field length must be 5 (in column 51), 
the length defined for a TABCST entry, and the number of 
decimal positions must be 2 to agree with the Extension 

sheet. 


USING TABLE DATA IN CALCULATIONS AND OUTPUT 


You perform a table lookup because you want the informa- 
tion referenced to be used in some way. In some programs, 
you may wish to.use the data in a calculation. At other 
times, you merely want the data to be used for output. 


Conditioning Operations on the Basis of a Table Lookup 


In the sales job, the specifications for a LOKUP operation 
instructed the program to search TABITM for an entry equal 
to an item in a SALES record and then make available the 
appropriate unit cost entry from a second table. If the 
search was successful, resulting indicator 05 would have 
been turned on. ; a Ga 


Providing the item code is carried in stock (successful 
search), you want to use its unit cost to determine the 


-amount the customer owes for the number of items or- 


dered. In other words, the calculation specification in line 
02 of Figure 8-16 should be performed. 
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Figure 8-16. Performing Calculations Only After a Successful Search, 


However, if the item code was not found, indicator 05 
would have been turned off and no cost entry would be 
available for the item ordered. For the example given, you 
could have the SALES record for the current lookup selec- 
ted into a separate stacker. In this way, you can identify 
which customers must be notified that their orders cannot 
be filled. 


Note: \n order to select a stacker for input records on the 
basis of a calculation operation (for example, LOKUP), the 
file must be defined as a combined file on the File Descrip- 
tion sheet and the stacker must be specified on the Output- 
Format sheet. See the chapter entitled Card Output Opere 
tions for a discussion of stacker selection. 


Ordinarily, all calculation specifications are performed be- . 
fore any output is done. But if the search for an item was 
unsuccessful, you would be unable to calculate a bill for 
the customer correctly. 
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Figure 8-17. Performing Output Only if Search Was Unsuccessful 
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Therefore, there must be a way to bypass the calculations 
if the lookup is unsuccessful. This is done by entering 05 
as a conditioning indicator in columns 10-11 (see Figure — 
8-16). The calculation operations will be done only when 
05 is on. In this way, the same resulting indicator used to 
determine the results of the lookup becomes a conditioning 
indicator to determine if a calculation operation should be 
performed. i . | 


If the item is not carried in stock (05 off), any calculations 
conditioned by 05 are not performed. The program then 
performs the output specifications since there are no more 
calculations to be done. (See Figure 8-17.) For this ex- 
ample, a card is selected into a different stacker only when 
the search is unsuccessful, not for every item ordered. Thus, 
the output specification is conditioned by entering NO5 

(05 not on) and the record identifying indicator in columns 
23-28. 
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At this point, then, you know that you may or may not _ 
want certain calculations and output specifications per- 
formed, depending on the results of a table lookup. This 
is accomplished by using conditioning indicators. 


Referencing Data Following a Successful Search 
According to the RPG Ii program cycle, input specifications 


are performed first, followed by calculations and then out- 
put. Thus, after reading a data record, all calculations for 


that record and then all output operations for that record are 


performed, before the next data record is read and processed. 


With this logic in mind, let's take a look at the output wanted 
from the table lookup program just discussed. TABITM con- 
tains the codes of all items carried in stock. The related table, 
TABCST, contains the unit cost for each item. ASALES | 

file contains the records of customer orders, providing the 
customer number, code for the item ordered, and the quan- 
tity ordered. 


The purpose of the program is to calculate the amount each 
customer owes and print the information on a report. The 
report’ is to contain more than just the total amount due, 
however. As shown in Figure 8-18, each order should have 
a line printed with data from the SALES record: (item or- 
dered, quantity ordered), data looked up from TABCST 
(unit cost), and data from calculations {total amount due). 


After the first SALES record is read into the computer, 
Figure 8-19 shows that TABITM is searched to find an entry 
equal to the item code on that SALES record (ITMORD). 

If a successful search is made, indicator 05 is turned on and 
the table entry looked up is available for use in further cal- 
culations or output operations. In this program, you want to 
multiply the /ooked-up cost by the number of items the 
customer ordered (field QTYORD on the SALES record). 
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Figure 8-18. Output from a Table Lookup 


What is the name of the field containing the cost? The 
specifications i in line 02 of Figure 8-19 shows this instruction. 
The name of the table (TABCST) which provided the cost 
has been entered under Factor 1. Whenever a table name : 
is used as a factor in any operation other than a LOKUP (in 
this case, the operation MULT), the name refers to the data 
item made available by a LOKUP. Thus, TABCST in line 

02 refers to the unit cost of the item just looked up. =~ 


Since the table name, TABCST, is used only as a factor and 
not as the result field of the MULT operation (line 02), the 
contents of the TABCST data item are not changed. It still 
contains the unit cost for the item on the sales record. | 


Once all calculations have been performed, the RPG Ii pro- 
gram performs the output specifications (Figure 8-20) for _ 
this same SALES record. The specifications in line 01 are : 
not performed, since the SALES record is selected into . 
stacker 3 only if the search is unsuccessful (indicator 05 | 
off). However, the rest of the output specifications are per- 
formed. Suppose the REPORT file is defined on the File 
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Figure 8-20. Output of Data Looked-up in a Table Search 


Description sheet as a printer output file. Lines 02-05 cause 


the data from the SALES record to be printed on the report. — 


By referencing the name of the table looked up (TABCST) 


in line 06, the program prints the data contained in the table | 


element, the unit cost for this first SALES record. Line 07 
then tells the program to print the amount due, which was. 
previously calculated. 


Once al] output has been performed for the first record, the 
RPG II cycle causes the input specifications to be performed 
again. Thus, the next SALES record is read in, and a table 
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LOKUP is performed for the second record. On a successful 
search, the unit cost for the second SALES record is made 
available. The cost for the second item can then be used in 
calculations and output specifications by referring to the 
name of the table looked up. 


Each table LOKUP operation performed searches for only 
one entry from a table. This data is then available to be 
used in calculations and output specifications for that rec- 
ord. The data available does not change until the next table 
lookup is performed for that table. 


Tables 8-17 


TABAMT TABTAX TABAMT TABTAX TABAMT TABTAX TABAMT TABTAX TABAMT 
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Searching For Low, High, or Equal Conditions 


Up to this point, table lookup operations have involved 
searching for only an equal condition. However, in some 
cases, you may have a search word which is less than or 
greater than an entry in the table being searched. 


Assume that a 3 percent sales tax is charged in the state in 
which you do business. Since the tax rate (3 percent) is the 
same for all amounts, it is a simple data processing opera- 
tion to calculate the amount of tax for every customer’s 
order. However, merely to show you how a low or high 
search works, let’s use a table lookup to determine the tax 
due on an order. 


The tax due on certain amounts is calculated, and the in- 
formation is organized into two tables (see Figure 8-21). 
TABAMMT is a list of various amounts of purchases while 
TABTAX contains the sales tax due on the amounts. 


Assume you had to lookup the sales tax for a customer 
order totaling $9.16. By placing a resulting indicator 
(01-99) in columns 58-59 of the Calculation sheet (Figure 
8-22), you specify that an equal condition is to be satisfied. 
The computer then searches TABAMT, starting at the be- 
ginning of the table, until the table entry 976 (representing 
$9.16) is located. At that time, the resulting indicator (in 
this case, 23) is turned on and the sales tax of 27¢ is made 
available. 
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Figure 8-22. Searching for an Equal Condition 


Factor 2 


On the other hand, what if a customer ordered items which 
total $5.76? TABAMT contains no such entry. Thus, indi- 
cator 23 is turned off, indicating an equal condition cannot 
be satisfied. What the calculation specifications shown in 
Figure 8-22, a correct tax amount will never be made availa- 
ble for this purchase. 


However, since TABTAX contains all possible tax amounts, 
a sales tax entry must be present for a purchase of $5.76. 
Looking at the two tables in. Figure 8-21, you can see that 

a sale of $5.49 requires a tax of 16¢ . But the sale was 
greater than $5.49; therefore, the tax will be more than 16¢. 
Take a look at the next entry. Fora sale of $5.83, the tax 
is 17¢. Furthermore, any sale which is less than $5.83, but 
greater than $5.49 (the previous entry), will also require a 
tax of 17¢. 


In this case, TABAMT is organized in ascending sequence. 
Therefore, the TABAMT entry (5.83) which will give the 
appropriate tax for $5.76 is the first TABAMT entry higher 
(greater) than the actual search word. 


As you learned previously, a resulting indicator must be 
used to indicate what condition is to be satisfied for a suc- 
cessful search. To specify that a LOKUP is to retrieve a 


~ table element higher (greater) than the search word, a re- 


sulting indicator must be entered in columns 54-55 (Look- 
up High) of the calculation specification. 
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Since customer orders can be any amount, the table lookup 
must be coded to handle all possibilities. For some orders, 
an equal match can be found in TABAMT; for others, the 
table entry will be higher than the search word. Therefore, 
the same resulting indicator (23) should be assigned to turn 
on if either a high or equal condition is satisfied (see columns 
54-55 and 58-59 of Figure 8-23). . 


A table can also be searched to locate an entry which is 
lower in value than the search word. In such a case, the 
table is searched for the entry which is lower (less) than, 
yet closest in value to, the search word. Searching for a 
low condition is specified the same way as searching for a 
high condition, except the resulting indicator is entered in 
columns 56-57, rather than 54-55. 


In coding a table lookup, either one or two conditions may 
be specified. A particular. search may be successful by sat- 
isfying: 

As An equal condition only. 

2. A high condition only. - 

3. A low condition only. 


4. Either a high or equal condition. 


5. Either a low or equal condition. 


Searching for either a low or high condition (for the same 
LOKUP operation) would not be specified, since a majority 
of items in the table will satisfy one of the two conditions. 
The condition(s) which must be satisfied can depend on the 
type of data in the table, the data used as the search word, 
and the sequence of the data within the table. 


Sequence of Tables 


To perform a table search for an equal condition only, it \ 
isn’t necessary that table entries be in any particular order. 
Starting at the beginning of the table, the table elements 

are checked, one at a time, until an equal entry is found or 

the end of the table is reached, whichever occurs first. 


However, when searching for high or low conditions, table 
entries must be in either ascending or descending sequence. 
This is because the program must select the entry which is 
higher or lower than, yet closest in value to, the search 
word. With the table entries in sequence, the program can 
determine where in the sequence the search word value 
would appear if it were in the table. For example, if table. 
elements 2-4-6-9-11 are in ascending sequence, a search 
word of 7 would naturally come between elements 6 and 
9. Thus, element 6 would satisfy the low condition, while 
element 9 would satisfy the high condition (closest in value 
and yet higher than the search word). 


Likewise, if the table is in descending sequence 1 1-9-6-4-2, 
the search word (7) would come between 9 and the 6. 
Regardless of the sequence (A or D), 9 would satisfy the 
high condition, while 6 would satisfy the low condition. 


If the table elements are not in sequence, as 2-4-11-9-6, the 
LOKUP might retrieve the wrong element. The elements ; 
are checked one at a time from the beginning of the table. L 
Therefore, the computer would determine that a search 

word of 7 would come between the 4 and the 11. A search 

for a low condition would incorrectly retrieve element 4, . 
because the next element (11) is greater than the search 

word (7). While the last element (6) is actually closer in 

value to the search word, it would not be made available. 
Likewise, a search for a high condition would retrieve 
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element 11, because it is the first entry encountered after 
element 4, which is greater than the search word. [Element 
9, which is closer in value, yet higher than the search word, 
would not be retrieved since the table is not in sequence. 


The sequence of a table is specified by entering an A or D 
under Table Sequence (columns 45 and 57) on the Exten- 
sion sheet (see Figure 8-24). When an entry is made in a 
sequence column, the RPG II program will check the table 
entries to ensure they are in the appropriate order (ascend- 
ing or descending) when loaded. 


Generally, table entries are arranged in ascending order, if 
a sequence is necessary. For certain applications, however, 
you may find descending sequence more suitable. For ex- 
ample, you may find that the entries with higher values 

are to be referenced more often. By placing such entries at 
the beginning of the table (highest to lowest), you may de- 
crease the amount of time required to search a table. 

Table entries to be in descending order are designated by 
entering a D in the columns 45 and 57, rather than an A. 


The fact that a table should be in sequence can affect the 
design of the table input record. In general, when using cards, 
table input records containing one entry per record 

(or pair of entries if alternating format is used) are more 
desirable for sequenced tables. In this way, when a se- 
quenced table is to be updated with additions or deletions 
the change cards can simply be inserted or removed. 


Moving Data in a Table Entry 


Suppose you wish to use a table TABCOD to LOKUP data 
from a related table, TAB123. TABCOD contains codes 
for all items carried in stock. TAB123 contains informa- 
tion about each of the items. 
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Up to now, we have discussed table entries containing 

single items of data. However, a table entry may contain 
more than one field of information. For example, each 
entry in TAB123 contains a 15-character item description, 
followed by a 4-digit unit cost with two decimal positions 
and a 3-digit quantity in stock. A pair of related entries 
from TABCOD and TAB123 might appear as in Figure 8-25. 
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Figure 8-25. Table Entries of More Than One Data Field 
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Figure 8-24. Specifying Sequence of Table Entries 
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As you know, following a successful search, you can use the 
entire looked-up entry in calculations and output merely by 
specifying the table name. If the table name TAB123 was 
specified on the Output sheet, the description, cost, and 
quantity would all be printed or punched, as follows: 10 
IN BAND SAW0950107. The data items would be run to- 
gether, just as they appear in the table entry. 


If a table entry contains several fields of data, often you 

may wish to use only part of the table entry in a particular 
program. For example, to do your billing, you need only the 
item description and cost from TAB123. To reference only 
part of an entry, the data in the TAB123 entry must be 
separated after the successful search. This is done by mov- 
ing the data from TAB123 into smaller separate fields, which 
can then be used in calculations and output. 


As shown in line 02 of Figure 8-26, first the contents of 
TAB123 are moved to the left into a 15-character alpha- 
meric field. This isolates the description, which can then be 
printed by referring to the DESCRP field name on output 
specifications. To isolate cost, which is in the middle of 
the table entry, you must first move it, along with one of 
the outer fields (quantity or description), into a temporary 
work field. Thus, line 03 moves the rightmost seven char- 
acters (cost and quantity) into an alphameric field, WORK. 
Since the cost is now in the left part of the WORK field, 
moving the field to the left only four places will isolate cost 
from quantity. In this way, the field COST can be used to 
reference only the cost information. Furthermore, COST 
is specified as a numeric field so that cost data is in the 
proper format for use in calculations. 
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Figure 8-26. Isolating Part of a Table Entry 
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The data from the table entry is now separated into new 
fields which can be used in calculations or to output the 
single items of data. 


Modifying the Contents of a Table 


At some point, you may wish to make changes to the data 
contained in a table. These changes can be temporary, for 
a particular run; or they can be permanent, such that every. 
time a job is run which references that table, the program — 
uses the changed table data. 


Making Temporary Changes to Table Data 


Temporary changes to the entries in a table can be made by 
calculation specifications which are actually a part of your 
RPG !I program. For example, two tables provide the item 
code (TABITM) and unit price (TABCST) for each part. If 
you change the price of a part for a particular run, you must 
necessarily change the entry in TABCST for that part. 


As Figure 8-27 shows, TABITM is searched to locate a cer- 
tain part code. On a successful search, the unit price for 
that part is made available from the corresponding entry of 
TABCST. This information is available for the table named 
under Result Field (line 01). 


By using the name of the table referenced (TABCST) in any 
operation other than the LOKUP (see line 02), you are ac- 
tually referring to the table entry last looked-up. Thus, by 
moving the field to TABCST, you are actually storing the 
new unit price for that item in the table. 
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Figure 8-27. Modifying a Table Temporarily 


As you can see, the use of a table name as the result field 
‘of a calculation operation is one means of modifying the 
contents of that table. Since the changes are indicated by 

_ specification entries, the changes must be planned for while 
you are still writing the RPG Ii program. Otherwise, the © 


instructions could not become a part of the object program. 


it is very important to note that any changes made to a 
table during execution of the program exist for that run 
only unless additional specifications are made that indicate 
a permanent change. Thus, the next time the program is 
run, the original table data is used. 


Making Permanent Changes to Table Data 


Whether the contents of a table must be permanently 
changed generally depends on the type of data contained 
in the table. For example, a table used to keep inventory 
records will undoubtedly change quite often. Assume a 


company uses a table to hold the quantity on hand for each | 


part manufactured. Every time the company manufactures 
more of a particular part or sells (and delivers) a part, the 
quantity on hand for that part must be increased or de- 
creased, accordingly. 


The only way to make a permanent change to the data in a 
table is to change the table input records. If the data is 
changed as a result of calculation specifications performed 
during a run, the changed data can be punched into. cards 
or written to another output device during the run. In this 
way, the output can be used as table input records for the 
next run. 
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Short Tables for Adding New Table Entries 


Rather than changing data already stored in a table, there 
may be cases in which you want to add additional data to 

an already existing table. For example, assume your com- 
pany wants to keep a list of employee numbers and hourly 
wages in two tables, TABEMP and TABWAG. At the pres- 
ent, there are 46 employees on the company payroll; thus, 
there should be 46 entries in each table. However, you know 
that the number of employees may increase to about 90-100. 
Therefore, you will want to add entries to the table as new 
employees are hired. 


At the time the table input records are set up, you must de- 
scribe them on the Extension sheet. This means that you 
specify the number of entries per table. If you were to spec- 
ify only 46 entries per table, it would be necessary to code 
new extension specifications every time the number of table 
entries changes. Since the extension specifications are com- 
piled and become part of the object program, it would be 
necessary to recompile the program to make such a change. 
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If you know beforehand that the size of your table will in- 
crease, you can initially build a short table. In a short table 
only some of the table entries contain actual table data. 
The program fills the unused entries with blanks. Thus, 
TABEMP and TABWAG can be defined as 100 entries each; 
although for now, you plan to use only 46 entries in each 
table (see Figure 8-28). Of course, be aware that enough 
storage will be reserved for 100 entries. The storage re- ; 
quired for the unused table entries will not be available to 
hold any other data. 
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As new employees are hired, the new table entries can be 
added by inserting additional table input records. The 
Original extension specifications still correctly describe the 
table, as they merely indicate the maximum number of en- 
tries allowed for each table. 


Whether the RPG II source program and the table input rec- 
ords must be recompiled depends on which method was 
selected originally for loading the table. The methods of 
loading tables and their effect on short tables is discussed in 
a following section. 
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LOADING TABLES 


Table data can be loaded into the computer at two different 
points: at the time your RPG Il source program is compiled 
(compile time tables) or at the beginning of your RPG II 
object program execution (pre-execution time tables. How 
often you wish to make permanent changes to the data con- 
tained in the table usually dictates the time at which you 
choose to load that table. The choice should be made as you 
plan your application, since your decision may affect the 
design of your table input records and the specification entries 
required. Furthermore, loading of the table input records 
differs, according to the type of table used. 


Compile Time Tables 


Tables loaded at the same time as your RPG II source pro- 
gram are referred to as compile time tables. In other words, 
the table file is compiled (or translated into the machine or 
object language) along with the RPG II source program. In 
this way, the table data is actually a part of the object pro- 
gram. Every time you run the particular object program, 
then, the table(s) are brought into storage at the same time 
as the program. As you can see, one definite advantage in 
creating compile time tables is that you avoid the necessity 
of loading separate table files into the computer every time 
you wish to run that object program. 


Changing Compile Time Tables 


Temporary changes to data ina compile time table exist 
only for a particular run and are made as easily as for any 
table. Calculation specifications which have been previous- 
ly coded in the program can modify any of the table 
elements. 


Making permanent changes to a compile time table or add- © 
ing new entries to a short compile time table requires re- 
compiling the entire RPG II source program along with the 
new or changed table input records. The object program 
produced then contains the current table data. Of course, 
this process of recompilation requires extra time. . 


Loading Compile Time Tables 


A table to be compiled with your program should follow 

the RPG II source program (Figure 8-29). There should be 

a record immediately before the table containing *” in posi- 
tions 1 and 2. Position 3 must be blank but remaining posi- 
tions may be used for comments, such as the table name. 

If more than one table is to be compiled, an ** record should 
be placed before each table. Furthermore, the compile time 






tables must be loaded in the same order as they are described 
on the Extension sheet. The end of file record (/* in posi- 
tions 1-2) which usually comes at the end of the source pro- 
gram is then placed after the last compile time table. 


Model 10 Disk System, Model 6, and Model 15 users may 
place compile time tables in the source library following 
the source program. The same record sequence as shown 
in Figure 8-29 is used. See the applicable reference man- 
uals for your system for specific procedures. 


Pre-execution Time Tables 


In general, if a table is to be permanently modified often, it 
is better to create a pre-execution time table. Such a table 
file is not compiled with your RPG II source program. In- 
stead, only the source program is compiled or translated . 
into the object program. Once the object program has been 
loaded into the computer to be executed, the table file is 
loaded separately. Like any other input data file, the table 
file is then used by the object program, rather than being a 
part of the program. 


RPG tf Source Program 


Card System Users: The source program 
and table input records as shown here 
are placed in the secondary MFCU 
hopper. The RPG. I! compiler program 
is placed in the primary hopper. 


Figure 8-29. Loading Compile Time Tables 
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Changing a Pre-execution Time Table 


Modifying a pre-execution time table takes much less time 
and effort than changing a compile time table. Modifying 
the contents of the table permanently (whether a short 
table or a full table) can be done by inserting and deleting 
change records. In any event, only the table file is changed. 
Since there is no need to make changes in the RPG II object 
program, it isn’t necessary to recompile the entire program. 


Loading Pre-execution Time Tables 


Pre-execution time tables are similar to any other input data 
files in that the RPG II object program uses the files when 
the program is executed. However, unlike other data files, 
pre-execution time tables are read completely before opera- 
tions involving the tables are done. An end of file record (/*) 
must follow every pre-execution time table file, regardless 
of whether the table is short or full (Figure 8-30). The ** 
record that precedes each compile time table is not used for 
pre-execution time tables. 


Table File 
(Short or Full) 





Model 10 Card System Users: The table files 
are loaded from the secondary MFCU hopper. 
The RPG If object program is loaded from 
the primary hopper. 


Other Systems: Table files loaded at pre- 
execution time may be loaded from console, 
cards, disk, or tape. 


Figure 8-30. Arrangement of Input for Pre-execution Time Tables 
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The table files should be in the same order as for compile 
time tables. All table files are to be loaded in the same 
order as they are described on the Extension sheet. Further- 
more, if both pre-execution time table files and other input 
data files are to be used by a program, all tables must be 
loaded before the data files. 


Specifications for Pre-execution Time Tables 


Since a pre-execution time table is a separate file to be used 
by the program, the entire file of table input records must 
be defined on the File Description sheet, just as any other 
file must be. This specification sheet is not required for 
compile time tables because the records are not used as a 
file. Instead compile time table data becomes a part of the 
object program. - 


Figure 8-31 shows the file description specifications required 
to define a pre-execution time table input file. A filename, 
different than the table name, should be assigned to the en- 
tire table file (columns 7-14). In this case, the file called 
SALESTAX contains data for both TABAMT and TABTAX. 
An/ in column 15 distinguishes that SALESTAX is an input 
file. Notice, also that the File Designation entry (column 
16) must be a 7, to indicate that this is a table file, as well. 
The Device entry (columns 40-46) indicates the device from 
which the table file is read; in this example, we are using 
MFCU2. 


Ordinarily, if an input file is to be in a particular sequence, 
an entry (A or D) is made in column 18 of the File Descrip- 
tion sheet. However, when specifying a sequence for table 
files, the sequence columns (45 and 57) on the Extension 
sheet must be used, rather than the sequence column on 
the File Description sheet. An & has been entered in col- 
umn 39 of the File Description sheet to indicate that the 
records in this table file are further described on the Exten- 
sion sheet. 


Looking at Figure 8-31, you can see that the filename as- 
signed on the File Description sheet is also entered under 
From Filename (columns 11-18) of the Extension sheet. 
This common entry tells the computer that the extension 
specifications describing TABAMT and TABTAX tables are 
associated with the SALESTAX file defined on the File De- 
scription sheet. For compile time tables, no entry is made 
in columns 11-18. This is because no file description speci- 
fications are made and, thus, no filename is assigned to com- 
pile time table records. 
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Figure 8-31. Defining a Pre-execution Time Table File 
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OUTPUT OF AN ENTIRE TABLE 


Up to now, we have discussed how to write or punch only 
individual table entries, one at a time. In this way, only 
table entries which satisfy a search condition (which have 
been placed in the hold area) have been used as output. 


For various reasons, you may want an entire table written 

or punched out. Perhaps you want a listing of the table en- 

tries to determine if any changes should be made. If your 

program updates a table, you may wish to output all the 

entries to be used as table input the next time the program 
is run. 


An entire table can be written or punched out only at the 
end of the job; that is, after all other output has been com- 
pleted (LR on). Even if the table is a short table, all entries 
are put out including those which are unused (blanks or 
zeros). 
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Writing or punching an entire table at end of job is very 

easy to specify. Just as for any type of output, the output 
file must be given a name and assigned to an output device 
on the File Description sheet. However, no output specifi- 
cations are necessary for end of job table output. You mere- 


ly specify the name of the output file in columns 19-26 of 


the Extension sheets on the same line'as you described the 
table input records. With the extension specifications shown 
in Figure 8-32, the table will be put out automatically at 
end of job. 


The output data may not be exactly the same as the 


’ input data, because table entries are put out as they are at 


end of job. Thus, if your program has changed or updated 
any table entries, the modified data will be put out, not the 
original data. Except for printer output, however, the for- 
mat of the table output records will be the same as the in- 
put records. . 
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Figure 8-32. Specifications for Output of Entire Table at End of Job 
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Review 8 


(Answers to review questions follow the review.) 


a. Design the table input records for an inventory table of item numbers. Each item 
number is a five-digit number. There are 123 unique items in stock. Use either one 
record per item or one record for a number of items. State the maximum number of 

"records necessary to contain the table data. State the minimum number of records 
necessary to contain the table data. , 

b. Assign a name to the inventory table. 

Define the table by.coding the necessary extension specifications. 

d. Code the calculation specifications necessary to search the table for an item num- 
ber which matches the item number ({TEMNO) on an order record. 

e. Why must a resulting indicator be specified in columns 58-59 of the Calculation 
sheet for the LOKUP operation? 


2 


a. Design alternating format table input records to create two related tables from the 
following data. Put one set of entries on each record. 


Item Number _ 


10° 
17 
27 
68 
102 
700 
1640 
2796 
4333 





b. Define the tables by coding the necessary extension specifications: 
c. Using ITEM as the search word, code the calculation specifications for a two-table 
search which makes the appropriate cost available. 


How does a programmer specify that a table search is to satisfy a high, low, or equal 
condition? 


What indicates whether a table lookup was successful or not? 


How does a programmer reference /ooked-up table data in calculation and output 
specifications? . “ 


If Jooked-up table data is to be referenced in calculations or output, how can a pro- 
grammer ensure that the appropriate information will be used? 


é 


How may table data be changed during execution of an RPG II program? 


What must be done to change table data permanently (to exist for more than the 
present run of the program)? 
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9. What is a short table? 
10. What is the advantage of using a short table? 
11. Which specification sheets are necessary to program for output of an entire table at 


end of job? What is the use of each type of specification required? 


Review Problem . 


To perform invoice billing, a corporation processes two input files together in a matching 
records program. As.the following input specifications show, the primary CSMSTR 
(customer master) file contains a record for every customer who has placed an order, giving 
the customer number, name, and address. The secondary ORDER file contains data about 
each order: customer number, item ordered, weight of item, and cost. 
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According to company policy, merchandise is delivered by truck unless a customer has re- 
quested delivery by parcel post. To date, the following 15 customers (by. pumber) have re- 
quested parcel post service: 


174 2109 596 1157 1475 
195 169 456 1366 377 
-.2105 2733 1100 290 1977 


The customer always pays parcel post vehaee The charge is in Sedordance with the weight 
of the ordered item,.as follows (assume no order weighs more than 30 pounds): 


8-30 
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WEIGHT IN POUNDS POSTAL CHARGES 





Note: Any fraction of a pound over the weight 
shown takes the next higher rate. 


To produce invoices, the billing program must do the following: 

a. Determine if a customer has requested parcel post delivery. 

b. If so, determine how much postage is required for the weight ordered. 

c. Print the amount of postage due on the invoice (printer output file named INVOICE). 
This can best be done by setting up three tables: 


@ A table of customers who have requested parcel post delivery. 


© Two related tables of weights and postal rates. 
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Your job is to: 


Design table input records for the three tables. The table of customers requiring par- 
cel post service should be created as a pre-execution time short table to allow for fre- 
quent additions and deletions. A table of 24 entries should be sufficient for contain- 


fo 


ing additions. The weight and postal rate tables should be loaded at compile time, 


since they will not be modified. 
Define and describe the tables with file description and extension specifications. 


Code the LOKUP operation(s) on a Calculation sheet to determine how much post- 
age is due, if any. 


Code the output specifications to print the amount of postage due on an order. 


vf 


Answers To Review 8 


a. The maximum number of records necessary to contain the table data is 123, with 


1. 


each record containing one item number entry in positions 1-5. The minimum 


number of records necessary to contain the table data depends on the maximum 


record length of the.device. For 96-column cards 


for example, the minimum 


’ 


Records one through six would each contain 19 item 


number entries punched in columns 1-95. Record seven would contain the remain- 


_ing nine item number entries punched in columns 1-45. For disk 


number is seven records. 


all entries could 


reside on a single record, since the maximum record length is 9999. 
b. The table name assigned (for example, TABINV) must meet the following require- 


ments: 


@ Three to six characters long 


@ May contain any numbers and alphabetic characters (including $, #, @) 


® Must begin with TAB 


® May not contain embedded blanks 
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To search for a high condition enter a resulting indicator in columns 54-55 on the same 
line of the Calculation sheet as you have specified the LOKUP operation code. 


To search for a low condition, enter a resulting indicator in columns 56-57. 

To search for an equal condition, enter a resulting indicator in columns 58-59, 

If more than one condition will satisfy a search, a resulting indicator should be entered 
for each condition. The same resulting indicator may be used for both conditions or a 


different indicator may be specified for each condition. 


The resulting indicator specified for the high, low or equal condition (columns 54-55, 


56-57, or 58-59) will be set on if the particular search condition is satisfied. The indi- 


cator will be off if the search was unsuccessful. 


In any calculation and output specifications which follow a LOKUP ppelanon, use of 
a table name refers to the table data found by the lookup. 


The resulting indicator specified with the LOKUP operation can be used to condition 
calculation and output specifcations that follow the LOKUP. 


When a table name is specified as the result field of a calculation operation, other 
than LOKUP, the result of the operation is placed in the table, replacing the last ele- 
ment looked-up. This assumes that a search was previously performed on the speci- . 
fied table. 


The-table input records must be recreated. If calculation specifications change table 
data during execution, the programmer may code specifications which cause the 
changed data to be output as new table records. The new output records can then be 
read in place of the old table input records the next time the program is run. 


A short table refers to table input records which contain fewer entries than the exten- 
sion specifications indicate the table can contain. 


The advantage of using a short table is that entries may be added to a table without 
changing the extension specifications which describe the table. 
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11. 


File Description sheet — assigns the name and device of the output file 


Extension sheet — indicates automatic table output at end of job when name of the out- 
put file is entered in columns 19-26 


Input, Calculation, and Output sheets — not required 


‘Answer to Review Problem. 


1. 





Customer Number Table Input Records 


Since the largest customer number is four digits in length, each entry would require 
four positions. A customer number less than four digits should be padded in front of 
the number with zeros or blanks, to form a 4-position entry. 


The simplest table input records to design and maintain for this table would contain 
one entry per record in positions 1-4. With this design, 15 records would be necessary 


for the 15-customer numbers. To add entries to the table, merely add table input 


records. 


An alternative method is to place the 15 entries in positions 1-60 of a single record. 

A record can contain a maximum of 24 4-digit entries. Entries may be added to the 
table by placing new customer numbers in unused positions of the same record. How- 
ever, to delete entries, the entire record would have to be recreated. 


Weight and Postal Rate Table Input Records 


The WEIGHT field from the ORDER input file is to be used as the search word for 
locating the appropriate weight in the table. Therefore, the weight table entries must 
be the same length and format as the search word: three digits in length with one 
decimal position. The corresponding postal rates can be three digits with two decimal 
positions, to accommodate the largest entry 1.05. 


Using an alternating format, one record could be used for each pair of entries (posi- 
tions 1-6), for a total of 30 table input records. Otherwise, the first 16 pairs of 
entries could be contained in positions 1-96 of one record with the remaining 14 pairs 
contained in positions 1-84 of a second record. 


If separate records are to be used for each table, the 30 weight entries could be in 
columns 1-90 of one record, and the 30 postal rate entries in columns 1-90 of another 
record. Using separate table format, 30 records would be required for each table, if 
each record contained only one entry. 
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2; Specifications to define and describe customer number table: 


File Description Specification 


Indicates this table file further 


described on extension sheet. File Addition/Unordered 
Number of Tracks 








Mode of Processing 
Length of Key Field or 
of Record Address Field 
. Record Address Type 
Filename Type of File 
Organization 

or Additional Area 


File Type 






File Designation 









tor DAM 












Name of 
Label Exit 








Symbolic 
Device 






Labels S/N/E/* 








Core Index 


Continuation Lines 


The devices used for these files 
can vary, depending which 
system and configuration you 
use. 
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table-input records must be loaded 
before other data files. 
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Short table: 9 entries may be added H 
to the 15 entries present. 











Specifications to define weight and postal rate tables: - 


Extension Specifications 
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No entry indicates 
compile time table 


File Description sheet not required since they are compile time tables. 


for Cylinder Overflow 


Number of Extents 
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Calculation specifications for LOKUP operations: 


— When a CSMSTR record is read (01 on), use CUSTNO field as search word 
Indicator 21 set on if 


Line 01 
to determine if that customer requires parcel post service. 
customer number in table. 


Line 03 — When an ORDER record is read (02 on) and that customer requires parcel 

post (21 on from successful search), then search weight table using WEIGHT field as_ 
search word. Indicator 23 set on when correct weight found (same number of pounds 

or next higher entry if weight is in fractions of pounds). When 23 is set on, correct postal 
charge is available from postal rate table. 


Form GX21-9093 
Printed in U.S.A. 
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Output specifications to print postal charge on invoice: 


Line 01 — If customer required parcel post and correct postage charge has been determined 
(23 on), print the postage chart from the postal rate table, TABRAT. 


OUTPUT 


rome [nn 


RPG 
tion 
75 76 77 78 79 80 
Program 
Identification 


Punching 


Field Edit 
End : Z = Zero 
Positon Suppress 


31432 33 34 35 36 37 


ReGae Be 
| fralariar 
pees 


eT 
Pe 
Ss 

ee 


| fs fof seer | F 
Lf fs of aster __ | 


P ff feof [>] 
Rw 
NO 
o 
yf tt 
N 
Pp ys 
wy 
o 





SPECIFICATIONS — tea 


‘ Chapter 9. Arrays 


CHAPTER 9 DESCRIBES: 


Use of arrays and RPG II coding to reference an entire array or individual elements 
of the arrays. 


XFOOT operation code. 


LOKUP operation code. 


BEFORE READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 
| Use of and coding for tables. 
Exception output. 
RPG II object cycle. — 


| OR relationship. 


> AFTER READING THis CHAPTER YOU SHOULD BE ABLE TO: 
Determine the use of arrays as opposed to the use of tables. 
Define an array on ie Extension sheet. 
Code problems that reference all elements in an array. 
Code problems referencing individual elements in an array. 
Define and code the LOKUP operation code with arrays. 
‘peeve data and store it in an array. 
Note: You can use the review questions contained fi Review 9 at the end of this 


chapter to test your comprehension of the chapter. Answers follow the review 
questions. 
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Page of GC21-7567-2 
Issued 24 May 1976 
By TNL: GN21-5389 


INTRODUCTION 


An array is a continuous series of data fields stored side by 
side so they can be referenced as a group. In an array, each 
individual data field is called an e/ement. Figure 9-1 shows 
an array of 12 elements containing the total sales for each 
month of the year. Each element of the array has the same 
characteristics; that is, each contains data in the same for- 
mat (alphameric or numeric), of the same length, and with 
the same number of decimal positions. An array element 
may be positive, negative, or unsigned; within a numeric 
array, elements may be positive or negative. 


An array is very similar in concept to a table. Both arrays 
and tables are set up by coding extension specifications. 
The type of data which you can put in an array is the same 
as that which you can put in a table. The data can be 
punched on cards, keyed in by the operator, or written on 
disk or tape. The data can be loaded into an array at com- 
pilation time or just before execution time. An array can 
also be built from data extracted from normal input files or 
from data produced during the program as a result of calcu- 
lations. The way data is arranged in storage is the same for 
tables and arrays; one element of data immediately follows 
another. The uses, however, of tables and arrays differ con- 
siderably. 


WHEN TO USE AN ARRAY INSTEAD OF A TABLE 


In most cases, tables contain constant data such as tax rates, 


shipping instructions, or discount rates. The constant data 
is then used for calculations or printing with variable trans- 
action data. Arrays are generally used for variable data and 
totals which are used independently of the variable trans- 
action data. | 


You should use arrays instead of tables when you want to 
reference all elements at one time. Arrays can reduce the 
number of RPG I! specifications you must code for such a 
program, as well as the time required to reference the 
entries. Arrays should also be used when you are able to - 
directly reference a data item within a group of items and 
do not need to do a look-up based on a search word. 


Each element 
six characters 
in lengthy 


1258.72 


Figure 9-1. 12-Element Numeric Array 
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0963.84 | 0792.38] 1462.98 | 2375.65 | 0865.97 | 1793.84 |0084.56 | 0693.58 | 1562.47 | 1237.96 | 0908.70 
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DEFINING AN ARRAY 


You tell the RPG I! program that you wish to set up an 
array by coding extension specifications in much the same 
way as you would code them for tables. As shown in Fig- 
ure 9-2, coding on the Extension sheet varies slightly, de- 
pending on when the array data is to be read into the array 
that is set up by the RPG II compiler. Array data can be 
stored in the array at three different times (see also eoaeing 
Arrays): 


1. Compile time. The array records immediately follow, 
and are compiled with, the source program. (If you 
have a Card System, both array data and source pro- 
gram are loaded from the secondary hopper.) 


2. _Pre-execution time. The array records are read like 
any other data file, except that they are all read be- 
fore any processing is done. (If you have a Card Sys- 
tem, both array records and object program are loaded 
from the secondary hopper.) 


3. Execution time. The array is loaded from informa- 
tion in input records or data generated by calculations. 


The following Extension sheet entries are used to define and 
describe arrays (see Figure 9-2): 


Columns 11-18 (From Filename): Pre-execution time arrays 
are read from an input file similar to other data files. The 
name of the file containing the array must be entered in col- 
umns 11-18 of the Extension sheet. This file must.be desig- 
nated as a table file in column 16 of the File Description 
sheet. A table file is read completely and data is loaded into 
the array before execution of the program begins. The same 
MFCU file can be named in these columns for more than 
one array. Input files on other devices can contain only one 
array. On the Card System, pre-execution time arrays must 
be loaded from the secondary MFCU hopper. 


Two decimal positions 
in each element 
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Extension Specifications 


Record Sequence of the Chaining File 


Number of the Chaining Field 
Table or 


To Filename 
: Array Name 


From Filename 


Figure 9-2. Defining Arrays 


Columns 19-26 (To Filename): \f you want your entire 
array to be written to an output file at end of job, enter 
the name of the output file in columns 19-26. You 
cannot use the To Filename entry to write execution 
time arrays to an output file; instead you must use 
output specifications (see Output. of an Entire Array, 
later in this chapter). 


Columns 27-32 (Table or Array Name): All arrays used in 
your program must be assigned a name of six characters — 
or less which is entered in columns 27-32. The rules for 
naming arrays are similar to those for naming tables; an 
array name can consist of any combination of alphabetic 
characters and numbers. However, while the first charac- 
ter must be an alphabetic character, an array name cannot 
begin with the letters TAB. This is the way the compiler 
distinguishes between an array and a table. 


Columns 33-35 (Number of Entries Per Record): For com- 
pile time and pre-execution time arrays, enter the number 
of array elements in each input record. These columns must 
be blank for execution time arrays. 


Columns 36-39 (Number of Entries Per Table or Array): 
These columns are used to enter the number of elements in 
the array (from 1 to 9999). This number should be entered 
so that the last digit is in column 39. 


Columns 40-42 (Length of Entry): The length of each 
element (number of characters, including blanks) should be 
specified in columns 40-42, with the number ending in col- 
umn 42. The length, which must be the same for every 
element in the array, cannot be greater than 255. 





Table or Length 
Array Name } of 
{Alternating 

Format) 


Decimal Positions 
Sequence (A/D) 


Column 43 (Packed/Binary): Disk or tape users may spe- 
cify in column 43 that pre-execution:time. array data is in 
packed decimal or binary format. On a disk system, 80- 
column card users can specify packed pre-execution time 
data. 


Column 44 (Decimal Positions): \f the elements in an array 
are numeric, the number (0-9) of digits to the right of the 
decimal point should be entered in column 44. Even if no 
decimal positions are present, a zero must be specified if the 
elements are to be considered numeric. A blank in column 
44 indicates that the elements are to contain alphameric 
data. Remember, however, that if arithmetic operations are 
to be performed on the elements, the array must-be defined 
as numeric. 


Column 45 (Sequence): \f your array data is in sequence, 
enter A (ascending) or D (descending) in column 45. Se- 
quence is not checked for execution time arrays, but this 
column must contain an any if high | or oe hs ue is used 
(see LOKUP of an Array). are po 


Columns 46-57 (Alternating Arrays): Columns 46 through 
57 are used if two related arrays are set up in an alternating 
format on input records. Alternating arrays cannot be de- 
scribed with execution time arrays. 


The extension specifications only reserve the appropriate 
space in storage for the array. Ina following section, you 


will learn how data is stored in the array. 
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REFERENCING ALL ELEMENTS IN AN ARRAY Array to Array Calculations 


Suppose a company employs 15 sales clerks whose daily Once the first SALES record is read and the data stored in 


sales are recorded on a punched card (SALES). As Figure | the DAY array, the 15 elements of DAY are added to the 
9-3 shows, field 1 contains sales for clerk #1, field 2 for 15 elements of MONTH. In other words, element 1 of 
clerk #2, and so on. There is one SALES. record for each DAY is added to element 1 of MONTH, element 2 to ele- 
day. In addition to a daily amount, the company wishes to ~ment 2, and so on (Figure 9-5). . 


have a monthly sales total for each clerk. Therefore, at the 
end of the month, the daily sales amounts for a clerk must 
be accumulated. 


As shown in Figure 9-4, an array (MONTH) of 15 elements 
is set up to contain ‘the monthly totals. Another array, - 
called DAY, could be set up to contain the 15 sales amounts 
for one particular day. The daily sales record is read and 
each clerk’s sa/es amount is placed in the appropriate 
element of array DAY. 










Daily ‘record 
for January 3 


Daily record 
for January 2 





: |elerk 1 | |clerk2 | |clerk3 | [clerk4 | = [clerk | 
Daily record Jclerk6 | |elerk7 | |clerk8 | |clerk9 | [clerk 10] 


for January 1 





lclerk 11| |cterk 12] [clerk 13| | clerk 14| |cterk 15] 


| Genk 3 | | clerk 2 | | clerk 3 | | clerk 4 | | clerk 5 | 





| clerk 6 | | clerk 7 | clerk 8 | | clerk 9 | | clerk 10| 
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| clerk 11 | | clerk 12| | clerk 13] | clerk 14| | clerk 15] 


SALES Records 


Figure 9-2. SALES Records 
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SALES record 
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sales 
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clerk 14 
sales 


clerk 15 
sales 
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clerk DAY array 
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MONTH array 





“\ Figure 9-4. Using Arrays to Contain Sales Data 
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DAY array (totals for day 4) 
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0072.1810142.96|0063.90) 0089.61 0076.95 ozone 0062.34/ 0079.83 psa 0148.75)|0063.69 |0057.24)0138.78/|0053.96 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
MONTH array (accumulated totals for days 1,2 and 3) 


serosa 0089.21/0098.54/0094.78/0148.00 oases orz04 0074.1 1)0168.42/0082.15|0070.69) 0167.15]0077.91 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 


. MONTH array (accumulated totals for days 1,2,3 and 4) 
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Figure 9-5. Adding One Array to Another Array 
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The 15 accumulated sale amounts (results of the additions) 
_are stored in MONTH. Then, another SALES card is read 
into the DAY array.’ The new DAY fields are then added 
again to the accumulated totals in MONTH. 


This method is similar to using two tables and adding an 
entry from one table to an entry in the other table. How- 
ever, performing the operations using tables requires more 
specifications than to doing the job using arrays. 


With tables, you must reference each element (sales amount 
for a clerk) separately. First, you must perform a table 
lookup to find the appropriate sale amount from the day 
table. Of course, since you do not know the amount of © 
each sale, you cannot search the day table directly. A re- 
lated table of sales clerk numbers must be set up and 
searched. Only after you find the.appropriate sales clerk 
entry is the corresponding sale amount in the day table 
made available. Then you must lookup the corresponding 
element of the month table. At this point, use of the table 
names in calculations or output would finally refer to each 
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: Program 
Page [4 of Identification 
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Program Punching 





‘for only one of the sales: clerks. ‘ 


oom [LDL 


of the entries looked up. An addition operation would then 
be required to add the two entries and place the result in the 
month table. After all this, you have accumulated a total a 


To repeat the same procedure 14 more times for the other 

sales clerks’ entries, the program must read 14 records and 

go through 14 program cycles. This occurs when you use a 
table name in specifications. The name refers to only one © 
element, the entry just looked up. 


On the other hand, if you have defined your groups of data 
as arrays rather than tables, only one calculation specifica- 
tion is necessary. The name of an array actually refers to 
all of the elements in that array. Adding the array DAY to 
the array MONTH causes every element of one array to be 


_ added to corresponding elements of the other array (1 to 1, 


2 to 2, 3 to 3, etc.). Since the MONTH array is specified 
under Result Field, the result of each addition is placed back 
into the appropriate element of MONTH (Figure 9-6). - 
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Notice on the Calculation sheet in Figure 9-6 that no result- 
ing indicators have been specified for this arithmetic opera- 
tion. When an array name is specified in a calculation, the 
operation is performed on every element of the array. There- 
fore, there are a multiple number of results; in this case, 15 
sales totals. A resulting indicator can indicate the condition 
of only a single result. Thus, resulting indicators cannot be 
used when referencing an entire array as a Result. Field. 
There are two exceptions when resulting indicators can be 
used, as explained under Adding All Elements Within An 
Array and Searching An Array For A Particular Element. 


Operations Which Can be Performed on Arrays 


As mentioned, an operation to be performed on an array is 
performed for every element in the array. A result is then 
produced for each element operated on. For this reason, 
certain operations cannot be performed on arrays, because 
the results have no meaning. The operation codes COMP 
(compare), TESTZ (test zone), MVR (move remainder), 
TESTB (test bit), BITON (set bits on), BITOF (set bits off), 
and DSPLY (display) cannot be used with an array. 


Performing Operations on Arrays of Different Lengths 


In the last example, all arrays used in an operation were of 
the same length; Factor 1, Factor 2, and the result array 
each contained 15 elements. Thus the operations were 
carried out until all elements were processed. 





DAY array 






MONTH array 


MONTH array 


Figure 9-7. Operations on Arrays of Different Lengths 


0016.21 | 0012.86 0026.31 | 0008.93 0017.83 | 0019.24 | 0015.67 | 0032.81 0042.21 | 0021.87 | 0019.67 | 0018.46 
1 2 3 4 5 6 7 8 9 10 11 12 


+ + + + + + + + + + + + : 
0072.18 | 0142.96 | 0063.90 | 0089.61 | 0076.96 | 0128.76 | or34.21 | o062.98 0079.83 0052.24 | 0148.75 | 0063.69 | 0057.24 | 0138.78 | 0053.96 
I 2 3: 4 5 6 7 8 9 10 11 12 13 14 15 


0087.39  orss.2 0089.21 | 0098.54 | 0094.78 | 0148.00 | 0149.88  ooss.15 | o1z2.08| 0074.11 | 0168.42 | 0082.15 | 0057.24 | 0138.78 | 0053.96 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 


Suppose, as shown in Figure 9-7, that DAY only contains 
12 elements while the MONTH array contains 15 elements. 
In such a case, the operations are performed only until the 
last element in the shortest array has been processed. Thus, 
the 12 elements of DAY are added to the first 12 elements 
of MONTH, and the 12 results are placed in the first 12 
elements of MONTH. The remaining three elements of the 
result field (MONTH) remain unchanged. Likewise, if the 
result array is shorter than any of the factors (arrays), the 
operation is repeated only for the number of elements in 
the shortest (result) array. 


Calculations Using Arrays and Single Fields (or Constants) 


Another way in which you can perform calculations on an 
entire array is by adding (or multiplying, etc.) the same 
value to every element in the array. For example, suppose 
the sales clerks are to receive a commission of 10 percent of 
their sales, to be paid at the end of the month. After all 
daily sales have been accumulated into the MONTH array, 
you want to multiply each of the 15 elements in MONTH 
by the value .10 and to place the commission amounts in 
another 15-element array called COMMIS. 


To do this, it is not necessary to set up a 15-element array 
for the commission rates, with each element containing 
the value .10. In an array operation, when one of the 
factors is a field (containing a value) or a constant, the 
operation is performed using the same field or constant on 
every element in the array. 









ee tl 


_ Unchanged 


Arrays 9-7 


You can also use a field or constant as both factors to place 
the same result in every element of an array. The calculation 
specifications in Figure 9-8 show the single field named 
DISCNT being subtracted from the single field AMOUNT, 
with the result placed in a 5-element array named DUE. The 
value (017) in DISCNT is subtracted from the value (243) 

in AMOUNT, and the result (226) is placed in each of the 
five elements of the DUE array. | 


Adding All Elements Within An Array 


In accumulating a monthly sales total for each clerk, the 
amount each clerk sold was determined. Suppose, in 
addition, the company also wants to know the total of all 
sales each day. 


As mentioned before, each clerk’s daily sales are stored ina 
separate element of a 1 5-element array named DAY. To 
obtain a total of all sales for the day, you must add together 
the contents of all elements in the array. The sum can then 
be placed in a single field. 


The XFOOT operation code (Figure 9-9, columns 28-32) 


_ tells the computer to sum the contents of every element in 


the array named in Factor 2. Columns 18 through 27.(Fac-  ~ 
tor 1) of the Calculation sheet are left blank since the — 

XFOOT operation involves only the values in one array. 

The sum of the DAY array elements is then placed in the 

single field named in columns 43 through 48 (Result Field). 


N, 


In most types of array calculations, multiple results are 
produced in accordance with the number of elements in an 
array. However, performing an XFOOT operation provides 
only one result, the total of all elements. For this reason, 
you specify a single field name rather than an array name, 
under Resuit Field. Furthermore, since there is only one 


result, a resulting indicator may be assigned in columns 


54-59 to determine if the sum is plus, minus, or zero. In 
this case, a resulting indicator was not specified (Figure 9-9) 
because the sales amounts will always be positive. | 
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Figure 9-8. Storing the Same Data in All Array Elements 
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Figure 9-9. Adding All Elements of an Array 


Output of an Entire Array 


You may want to have an entire array written or punched 
out. Perhaps you want to look at the contents of the array 
at some point during the program run or at the end of the 
run. Or, you may want to have array elements put out to 
be used as input the next time the program is run. Output 
of an entire array can be specified in two ways, with exten- 
sion specifications or with output specifications. 


Arrays 9-9 


By Extension Specifications ; By Output Specifications 


Like tables, compile time arrays and pre-execution time The second method of specifying output of an entire array 
arrays can be written out at end of job by simply entering is with output specifications. By specifying the array name 
the name of the output file under To Filename (columns under Field Name (columns 32-37) on the Output sheet, all 
19-26) on the Extension sheet (see Figure 9-10). The out- elements within the named array are punched, printed, or 
put file must be named on the File Description sheet, but written on the indicated output file (Figure 9-11). All types 
no output specifications are necessary. The entire array, of arrays, compile, pre-execution, and execution, can be pu 
including unused elements (blanks or zeros), is put out. out using output specifications. — 
With the Extension specifications shown in Figure 9-10, _ Any output conditioning indicators specified in columns 23 
the array, ARRAY1, is put out automatically at end of job. through 31 of the Output sheet determine when during the 
program the array elements will be printed or punched. If 
The data output may not be exactly the same as the data no indicators are specified, the entire array is printed or 
input. Your program can change or update array entries, punched every time a record is processed. Indicators can be 
causing modified data to be put out, not the original data. _ specified to put out array data during detail cycles or at 
Except for printer output, however, the format of the ~ total time. You may want to put out array data at total 
array output records will be the same as the input records. time by customer or inventory item, for example, to be 


used as input to subsequent update runs. 
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Figure 9-10. Specifications for Output of an Entire Array at End of Job 
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Figure 9-11. Output of an Entire Array — 


RPG II determines where the array data is to be put out on 


a card, printer file, disk or tape by the end position column ~ 


you specify in columns 40 through 43 of the Output sheet. 
The array elements are put out such that the last element of 
the named array ends in the column indicated. Note, how- 
ever, that if all elements in the array cannot be put out on - 
one output record, the array elements must be referenced 
separately on the Output sheet. Output of individual ele- 
ments will be discussed later. 


The output of an entire array by means of output specifica- 
tions requires only one specification. An entire array can 
be written, printed or punched at any time during the run 
or at end of job, depending on how the output specification 
is conditioned. Again, during the run, this is possible only 
if a single output record can contain this entire array. 


You must specify how you want the data elements to appear 
on the output record. Alphameric elements appear on an 
output record just as they appear in storage; however, 
numeric array elements may be edited or unedited. If no 
editing is specified, the elements are printed or punched just 
as they appear in storage, with the last element ending in the 
end position column of the output file. In other words, one 
element will immediately follow another with no punctua- 
tion and no blanks between elements. 


_ Usually, printed array output is easier to read and has a 


better appearance if edit codes or edit words are used to 
punctuate the data and insert spaces between elements. If 
punched output, disk output, or tape output is desired, 
generally the array output records are used as input the 
next time the program is run. Therefore, editing is usually 
not specified, so the elements will be in the appropriate 
format to be used as input. 
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Editing affects the position which is specified as the end 
position of the output record. If each element in a 5- 


‘element array contains seven characters, 35 positions would 


be necessary to output the entire array in unedited form. 
On the other hand, if punctuation and blanks are inserted 
for each element, the number of positions required increases. 
When specifying an end position, you must allow enough 


positions to output all edited elements. 


Réuardiass of whether editing i is specified 0 or not, when out- 
put of an entire array is performed, every element of that 
array is put out in the same format. If an edit code or edit 
word is specified, every element is edited in the same way. 
Since all elements of an array contain the same type of in- 
formation, ordinarily you want the elements punctuated in 
the same way. If, however, one element must be edited dif- 
ferently from another element in the same array, you must 
put out the elements separately. The means of referencing 
individual elements of an array is discussed later in this sec- 


"tion. 


When an edit code is specified in column 38 of the Output 
sheet, every element of the named array will be punctuated 
accordingly. Furthermore, any edit code specified for an 
entire array also causes two blank spaces to be inserted be- 
tween each element. The insertion of blanks is taken into 


. consideration by the program so that the pa element ends 


in the ppOsIgon specified. °° 3" .auhey. 
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As shown in Figure 9-12, the edit code 3 causes all five blanks to be automatically inserted in the output record be- 



























































elements of the SALES array to be printed with decimal fore each array element. Figure 9-13 shows an edit word ee 
points inserted, leading zeros suppressed, and zero balances specified without blanks; one element of SALES immedi- Noe 
present. In addition, two blanks are automatically printed ately follows the next on the output record. Any extra 
before each element since an edit code was specified. blanks which are to appear must be indicated in the edit 
word by an &. Notice, in Figure 9-14 that the two blanks 
If no edit code specifies exactly how you want the array specified are to be printed as part of every element. Thus, - 
fields to be edited, you can specify the punctuation by the second blank following the last element will be the 
using an edit word (columns 45-70). In this way, you can character which ends in the end position column. Notice 
edit array elements with dollar signs, zero suppression, that an additional two columns have been allowed for each 
blanks, constant words, or any combination of punctuation element (five elements). The end position column has thus 
desired. When edit words are used, all punctuation must be been increased by ten over that in Figure 9-13. 
specified. Unlike edit codes, edit words do not cause two 
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Figure 9-13. Output of an Entire Array With Edit Words 
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Figure 9-14. Editing Every Element of an Array 
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Accumulating Groups of Totals 


As you have seen, arrays can be used to accumulate a total. 
In a previous example, elements containing daily sales were 
added to obtain monthly totals, which were stored in the 
MONTH array. . ‘ta . 


To carry this concept further, one of the most common 


uses Of arrays is accumulating more than one group of totals. | 


Such a procedure is called ro/ling of totals, since one total 
is used to obtain a greater total, which is then used to cal- 
culate an even larger total, and.so on. Each total is ro/led 
into or accumulated into the next total. 


Figure 9-15 shows the organization of the Nelson Company. 
The company’s two regions are each divided into three 
branches, which are.in turn made up of two to six stores 
each. 
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Figure 9-15. Company Organization by Groups 
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NELSON COMPANY 


Company sales data is recorded on cards as shown in Figure 
9-16. For each store there is a separate record providing 
the 12 sales amounts for each month of the year. The sales 
records are organized such that stores are grouped within a 
branch and branches grouped within a region. Three one- 
position fields on each record identify it with a particular 
store, a particular branch, and a particular region. 
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Note: The same sales data shown 
here in punched card form could 
be keyed directly into the system 
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Figure 9-16, Sales Records Organized by Groups Within Groups 
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Figure 9-17. Sales Report by Groups Within Groups 
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A sales report must be produced showing the monthly sales 
for each store, for each branch, for all branches within a 
region, and for both regions (the total monthly sales of the 
entire company). The report, a series of accumulated totals, 
should look like the one in Figure 9-17. 


To produce the report, four arrays of 12 elements each 
should be set up, as shown in Figure 9-18. The first array, 
STR, will be used to hold the 12 sales amounts entered from 
the sales records. The other three arrays will be used to ac- 
cumulate the necessary totals for each branch, each region, 
and the entire company. 


In general, this program should accumulate store totals into 
the BRNCH array, branch totals into the REG array, and 





SALES record 
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STR array 


region totals into the COMP array. Thus, the specifications. 
must perform two functions: 


@ Add all elements of one array to all elements of another: 
array. 


'@ Print all elements of each array: 


To have the program produce the correct totals, you must. 
specify that one array is to be added to another array and 
printed. To do this, the two fields which identify a record 
with a particular branch and region should be specified as 
control fields. A change in the branch (or region) control 
fields will cause a control break, indicating the records for 
all stores in a particular branch (or region) have been proc: 
essed, 
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Figure 9-18. Four Arrays for Group Totals 


Arrays ‘9-17 


As shown in Figure 9-19, control level indicator L1 is turned 
on when the first record is read for a store in a different 
branch. Likewise, L2 is turned on (and thus L1 is automat- 
ically turned on) when the first record is read for. a store in 

a different region. The specifications on lines 06-17 merely 
describe the store sales data for each month of the year. 


The specifications in Figure 9-20, insert A, illustrate how 
control level indicators are used to control the performance 
of calculations and output. | 


As a sales record is read, the. 12 monthly totals for that 
store are placed in the array STR. (How data gets into an 
array will be discussed later.) Each time new data is placed 
in STR (every time a card is processed), the elements are 
added to the BRNCH array to accumulate totals for the 
branch (Calculation sheet, line 01). The store totals are 
printed as each record is processed, because every time a 
new card is read the data previously in the STR array is re- 
placed by the totals for the next store (output lines 01-02). 


When all store records for a particular branch have been read 
and their totals printed and accumulated in the BRNCH ar- 
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ray, an L1 control break occurs. The control break is indi- 
cated by reading the first store record in the next branch. , 
Before processing this next record, the branch totals are. , 
printed and the BRNCH array is filled with zeros to prepare 
for accumulating the next branch totals (Figure 9-20, insert 
B, lines 03-04). Before printing and zeroing the BRNCH 
array, however, the branch totals are added to the REG array 
(Calculation sheet, line 02). 


The same program cycles are repeated for the rest of the 
records in region |. Remember, however, that data is ac-. 
cumulated into the REG array only when processing for a | 
branch is complete (L1 on). | 


Once records for all branches within region | have been proc- 
essed, L2 is turned on, indicating the first record in the next 
region has been read, but not yet processed. With L2 on, — 
the 12 accumulated region totals are printed (Output sheet, 
lines 05-06). Before output of the REG array, however, cal- 
culations conditioned by L2 on are performed; that is, the 
region totals are added to the company array COMP (Calcu- 
lation sheet, line 03). The calculation is done before output 
so the region totals can be saved before REG is filled with 
zeros. 
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Figure 9-19. Identifying Groups by Assigning Control Level Indicators 
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The same procedure is followed for all store records in 
region If. During every program cycle, the store totals are 
printed and accumulated to form a branch total; when L1 
is on, the branch total is printed and accumulated into a 
region total. 


When the end of file is reached, the LR indicator is turned 
on. Automatically, all control level indicators assigned (L1 
and L2) are also turned on. Therefore, after the last store 
record has been printed and the store totals added to 
BRNCH (Figure 9-20, insert A, line 01), any specifications 
conditioned by L1, L2, or LR are performed. In other 
words, the totals for the last branch are added to REG (Fig- 
ure 9-20, insert A); then the region totals are added to 
COMP. Following the calculations, three sets of totals are 
printed; totals for the last branch (Figure 9-20, insert B, 
lines 03-01); then the region II totals; and, finally, the com- 
pany totals. 
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Figure 9-20. Accumulation and Output of Group Totals Using Arrays 
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REFERENCING INDIVIDUAL ELEMENTS OF AN 
ARRAY 


In addition to referencing all elements of an array, you can 
use an individual array element in calculations or output. 
Suppose you have an array with each element containing 
the quantity in stock of a particular part manufactured by 
your company. Element 1 contains the quantity in stock 


for part #1, element 2 for part #2, and so on. When a ship- 


ment of ordered parts is received, the quantity in stock 
must be updated to reflect the current inventory. This 
means you should reference (add to) oy particular elements 


. of the array. 
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Arrays 9-19 


Indexing an Array 


As you learned, if a calculation or output specification con- 
tains an array name alone, that specification is automatically 
performed for every element of the array. To reference only 
a single element of an array, you must identify that element 
for the RPG II program. This is done by placing a comma 
after the array name, followed by an index which points to 
the particular element (Figure 9-21). This index can be 
either the actual number of the element to be referenced or 
the name of a field containing the number of the element to 
be used. 


Recall Defining an Array. The name used to refer to an ar- 
ray cannot exceed six characters in length. When referencing 
individual fields, both the array name and an index are nec- 
essary to refer to the data. Therefore, usually the array name, 
plus the comma, plus the index cannot exceed six characters. 
The name used to refer to an individual array element must 
be one to six characters long unless the name (with index) 
used to refer to an individual array element is specified on/y 
as Factor 1 or Factor 2 on the Calculation sheet. In this 
case, the array name plus comma plus index may be as long 
as ten characters. However, the array name portion of the 
reference still cannot exceed six characters. 


Figure 9-21, line 01, shows a valid reference to the ninth 
element of an array named ARY1. However, if the array 
contains ten or more elements, some of which may have to 
be referenced, the name of this array would have to be 
shortened to provide enough positions for the index (Fig- 
ure 9-21, line 04). The limit of six characters applies even 
if the name of a field is used as an index. As line 07 shows, 
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Figure 9-21. Referencing a Particular Element of an Array 
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CELE 


if an index field IF LD is specified, only one character (B) 
can be used as the name of the array because the indexed 
name is specified under Result Field. However, COM, 
INDEX on line 07 is valid, even though longer than six 
characters, because it is specified only under factor col- _ 
umns, 


Specifying an Index Which Does Not Change 


If you know exactly which element is to be used in a calcu- 
lation or output operation and the specification is to ref- 
erence the same element in every program cycle, you may 
use a constant as the index. Assume a 7-element array 
(SLS) is defined to contain a salesman’s six daily commis- 
sion amounts and his total commission for the week. The 
six daily amounts from one of the salesmen’s input records 
are read into elements 1-6 of the array. The seventh 

field on the input record contains zeros and is read into 
element 7 of the array (Figure 9-22, insert A). : 


The array elements are defined as 5-digit numbers with two 
decimal positions. Once the data is in the array, the XFOOT 
calculation operation is performed to add all elements of the 
array and place the total in the seventh element (Figure 
9-22, insert B). The weekly total for every salesman is al- 
ways stored in the seventh element. Therefore, the actual 
number 7 can be specified as the index. In addition, a $25 
bonus is to be added to a salesman’s total if his weekly com- 
mission exceeds $175 (Figure 9-22, insert C). Thus, in every 
program cycle, element 7 must first be compared to $175 to 
determine if the bonus is to be added to the contents of . 
element 7. 
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Figure 9-22. Specifying a Number as an Index 
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Specifying an Index Which Can Be Changed | | 


On the other hand, if the array element will vary when a 
particular specification is performed, the index should be a 
field name rather than an actual number. In this way, the 
number stored in the index field can be changed during the 


program to indicate which array element is to be referenced. 


An array (STK) is used to contain the quantities in stock of 
all parts manufactured by a company. Element 1 of the ar- 
ray contains the quantity for part #1, element 2 for part 
#2, and so on. When additional parts are manufactured, the 
values in the appropriate elements must be updated. There- 
fore, records are punched daily for each type of part pro- 
duced. Each record contains the part number (NM) and the 
quantity of that part produced (QTY). 


To perform the updating, the contents of the QTY field 
must be added to one of the array elements for every rec- 
ord processed. Thus, an index must be used in order to 
reference only the individual element to be updated. Since 
each daily record is for a different part number, the array 
element to be increased will vary each time the specification 
is performed. For this reason, an actual number cannot be 
specified as the index, because QTY would be added to the 
same element for every part number. Instead, the NM field, 
which contains the part number for each record, can be 
specified as the index (Figure 9-23). Then, every time the © 
addition specification is performed, the part number just 
stored in NM indicates which element of the array is to be 
referenced. 
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Figure 9-23. Specifying the Name of a Field as an Index 
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Output of Individual Elements of an Array 


To put out individual elements of an array, you code the 
same output specifications you would for normal fields. 

The only difference is that under Field Name on the Output 
sheet you must specify the array name followed by a comma 
and an index. The index then points to the particular 
element to be put out (Figure 9-24). 


Thus, referencing individual array elements for output is 
the same as referencing them for calculations. If the same 
element is to be put out every time the output specification 
is performed, an actual! number can be used as an index. 
Otherwise, if different elements are to be put out individu- 
ally, a field should be specified which contains the changing 
index value. In any case, the array element (array name 
plus comma plus index) on the Output sheet cannot exceed 
six characters in length. 


Edit codes and edit words can be used to punctuate an in- 
dividual numeric array element. If an entire array is to be 
put out but the elements require different punctuation, each 
element and its editing should be specified individually. 
Editing to be done on an individual array element is specified 
and performed just as it would be for any normal element. 
This means that, if an edit code is specified for an individual 
array element, two blanks are not automatically inserted be- 
fore the element, as was the case with an entire array. Fur- 
thermore, although any type of output can be edited, editing 
is generally not specified for an array element which is to be 
punched on a card or written on disk to be used as input to 
another run, | i 
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Figure 9-24, Output of Individual Array Elements 


Referencing Only Part of a Field 


When a field is referenced in a specification, all characters 
within that field are used in the calculation or output. 
However, you may wish to reference only some of the data 
stored in a field. For example, consider the case during 
address printing where the ‘zip code is within the same field 
as the city and state on an input record but must be printed 
ona separate line on the output record (Figure 9-25). 


Input record 


|45876| NELSON KENNETH RAY 


|14618 RUSSELL AVENUE NORTH] 


ROCHESTER, MINN 55901 





ROCHESTER S5MINN65590 1S BOOS 


CSZ field 


Figure 9-25. Referencing Parts of a Field Separately 
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The indexing capability of arrays can be used to enable you 
to reference specific characters from an input field. This is 
accomplished by setting up two arrays; one to contain the 
entire field of data and one to hold only the Specie charac- 
ters you want to reference. 


Output record 









NELSON KENNETH RAY e 
’ ; : MENUE NORTH 





OCHESTER, MI 


AE CSZ field to be printed as: 


Arrays 9-23 


First, the entire field from which you wish to use data is 
stored in an array of the same name as shown in Figure 
9-26: (See Loading Arrays, Storing Input Data into Execu- 
tion Time Arrays \ater in this chapter for an explanation of 
this method of loading an array.) This array is previously 
defined as containing as many one-byte elements as there 
are characters in the field to be referenced. Thus, each 
character of the one field is actually stored in a separate 
element of the array. The array elements can then be ref- 
erenced one at a time (using an index) until an element con- 


taining a specific character is located. This process of check- 


ing | the elements of an array for particular data is referred to 
as field scanning. . 


After scanning the elements and locating a specific charac- 


ter, you can then move that character and any characters: 
(elements) on either side of it to a smaller array. This ar- 


CSZ field (30 characters) 









ROCHESTER,SMINN65590 ThsSESSIOD 


ray will then contain the portion of the original input field 


' which you wish to reference separately in calculations or 


output. 


For an address printing program, let’s assume the input records 


are defined as shown in Figure 9-27. The CSZ field contains 
the city/state and zip code. Although names of the city and 
state may vary in length, the zip code is always five digits 
long. Any righthand, unused positions of the CSZ field will 
contain blanks. 


The two arrays for this program are defined with the exten- 
sion specifications in Figure 9-28. CSZ is set up to contain 

30 elements, one for each character of the CSZ field from = 

the input record. The five elements of the ZIP array will be 
used to contain the zip code portion of the CSZ field. 


fefofe[ufels{rjeta].fo[mfify [jes ]s]e fof fslslojels|s|slsls| 


CSZ array (30 elements) 


Figure 9-26. Isolating Part of a Field 
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ZIP array (5 elements) 
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Figure 9-27. Defining a Field to be Scanned CSZ field 
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Figure 9-28. Defining Arrays for Field Scanning 
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To locate the zip code in the CSZ array, the elements must 
be scanned one at a time, beginning with the last (rightmost) 
element of the array. Thus, the index field (C) for refer- 
encing the individual fields of CSZ is initially set up in the 
Calculation sheet to contain the value 30 (Figure 9-29, line 
01). When the last (rightmost) character of the zip code is 
located, it should be moved to the rightmost (fifth) element 
of the ZIP array. Therefore, a5 is initially set up in the in- 
dex field (Z) which will reference a particular eg of ZIP 
ee 9-29, line 02). 


With the index fields set up, the program can begin scanning 
CSZ for the zip code. The elements of CSZ are checked, 
from right to left, until the first nonblank character is 
located. As line 04 shows, a character is compared toa 
blank. If it is blank, the index value is decreased (line 05) 
so the next character to the left can be compared to a blank. 


When one of the characters checked is not a blank (indicator — 


20 off), the last character of the zip code has been located. 
This ends the field scanning. 


The program can now proceed to perform the next group of 
calculations which move the located character to the right- 
most position of the ZIP array (line 09). The character in 
the CSZ array which was moved to the ZIP array is now 


. made blank (line 10) so the city and state line can be printed 


without the zip code. The index values for both arrays are 
decreased by 7, so the next zip code character (to the left. 
of the last one moved) can be moved from CSZ to the next 
portion in the ZIP array. When the value of Z becomes 0 
(indicator 21 is on), all five characters of the zip code have 
been moved to the ZIP array and made Blanket in the CSZ . 
array. 


- After calculations, the output specifications in Figure 9-30 | 


cause the name and address to be printed. The NAME and 
STREET fields are printed exactly as they appear on the in- 
put record. City. and state, on the other hand, are printed 
from the CSZ array rather than the input field, because the 
zip code has been blanked out. The zip code, which was 
moved to the ZIP array, is then printed alone on the next 
output line. 7 oe 
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Figure 9-29. Field Scanning 
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Figure 9-30. Output of Part of a Field 


LOKUP OF AN ARRAY _~ . . 1. 
Searching an Array for a Particular Element 2. 
An array can be searched to determine if a particular . 3. 
element of data is stored in the array. Actually, the array 

lookup is coded and performed in almost the same way as 4, 
a single table lookup. As the Calculation sheet in Figure 

9-31 shows, you specify: 5. 
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Figure 9-31. Searching an Array for a Particular Element 


SPECIFICATIONS 


= aa errs 





nil Si Ss NT 
ES 
o 








GX21-9090 U/M 050° 
Printed in U.S.A. 


1 76 77 78 79 80 


1:2 
Program 
fe LU] oe Identification 
Zero Balances X = Remove 
eae no 


Yes 
Yes No Field Ecit 
Z = Zero 
Suppress 


Constant or Edit Word 


6 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70471 72 73 74 


The search word to be used. 


The LOKUP operation code. 


The array to be searched. 
The condition which must be satisfied. 


The resulting indicator which turns on if the condi- 
tion is met. 


Fors rm neat -9093 
in U.S.A. 


75 76 77 78 79 80 
Program 
Identification 


Comments 


Condition which satisfies search 
and which resulting indicator 
is turned on 


Arrays 9-27 


Page of GC21-7567-2 
Issued 24 May 1976 
By TNL: GN21-5389 


The array lookup continues, one element at a time, until 
the search condition is satisfied or the end of the array is 
reached, whichever occurs first. As is the case for table 
lookups, array elements must be in sequence (A or D) if 
searching for either alow or high condition. Additional 
coding is necessary if searching an out-of-sequence array 
for either high or low. (See Searching an Array for More 
Than One Element and Output During an Array Search.) 


Although array and table searches are similar, there is an 
important difference you must be aware of. Remember, 
the array lookup is similar to a single-table lookup, not a 
two-table lookup. Only one array is specified in the look- 
up. operation. Any element which is referenced as the result 
of a successful search can only be from the array. actually 
searched. In other words, the array can not be searched to 
make an element from another array available, as is the case 


when two related tables are used in a lookup operation. For . 
this reason, no result field may be specified in an array look- 


up operation. 


Starting the Search at a Particular Element 


Another very important difference between tables and ar- 
rays concerns where the search can begin. Ina table search, 
only the name of the table to be searched can be specified 
as Factor 2 of the lookup operation. As a result, a table 
search always begins at the first table element. Likewise, if 
only an array name is specified as Factor 2 of a lookup 
operation, the search automatically begins at the first 
element of the named array. 
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‘Figure 9-32. Starting an Array Search at a Particular Element 
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With arrays, however, you also have the capability of be- 
ginning an array search at any element you specify. Under 
Factor 2, you specify the array name, followed by a comma 
and an index. The index, whether an actual number or the 
name of a field containing a number, points to the array 
element where the search is to begin (Figure 9-32). 


In a large array where you know that the value you are 
searching for is not in a particular section of the array, 
search time can be greatly decreased by beginning the 
lookup at a particular element. Suppose you have a 300- 
element array name ARY containing the values 001 through 
300 in ascending sequence. To locate a value of 047, only 
47 elements would have to be checked before the search 
condition was satisfied. However, to locate the value 289, 
289 elements would have to be checked, /f the search began 
at the first array element. 


Now, divide the array into three parts of 100 elements each: 


Elements 1-100: values 001-100. 


Elements 101-200:. values 101-200. 


Elements 201-300: values 201-300. 
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For any value of less than 101, the first third of the array is 
searched, beginning at element 1. For values greater than 
100, but less than 201, the second third of the array is 
searched, beginning at element 101. Likewise, a search is 
started at element 201 to locate any value greater than 200. 
In any case, no more than 100 elements have to be checked 
to satisfy the search condition. 


For this example, the number of the array element at which 
the search is to begin will vary, depending on the value being 
searched for. Figure 9-33 shows that three LOKUP’s have 
been coded. Only one of the lookup operations is performed 
for a particular value. 


To determine which LOKUP (line 04, 05, or 06) is per- 
formed, you must first determine in which part of the array 
the value is located. The first COMP (compare) operation 
(line 02) checks for a value in the first 100 elements. If the 
value is less than 101, indicating the first one third of the 
array, indicator 33 is set on. If 33 is on, the LOKUP begin- 
ning at element 1 is performed (line 04). However, if the 
value is not in the first third of the array (33 off), another 
compare (line 03) is necessary to determine if the value is in 
the second third of the array (indicator 44 set on). Thus, 
the LOKUP beginning at element 101 (line 05) is performed 
with indicator 44 on. If neither indicator (33 or 44) was set 
on, the value must be in the last third of the array, if it is in 
2 the array at all. Therefore, with both 33 and 44 off, the 

) LOKUP beginning at element 201 is performed. 


For the first LOKUP (line 04), it is not necessary to actually 
specify the numeric value 1 as the index, in the same man- 
ner as 101 is specified for the second LOKUP. When no in- 
dex is specified with the array name, the search automatic- 
ally begins at the first field, as if the index were 1. 


Note: Setting off indicator 44 (line 01) prevents an error 
in the lookup function. What would happen if the SETOF 
operation was not used and indicator 44 was set on in the 
first cycle and 33 in the second cycle? In that case, 44 
would not be set off in the second cycle because the N33 
condition would not be satisfied in line 03. Thus, both 
lines 04 and 05 would be executed. The LOKUP operation 
in line 04 would be successful and indicator 66 would turn 
on. The LOKUP operation in line 05 would not be success- 
ful and 66 would be turned off. Thus, a not-found condi-. 
tion would result even though the LOKUP was successful. 


If the value of the index changes, as in this case, you can 
use an index field to contain the number of the array field, 
rather than using the actual number. In this way, it is nec- 
essary to code only one LOKUP. Of course, you must 
place the appropriate number in the index field every time 
before the lookup operation is performed. Thus an index 
field will not always reduce the number of specifications 
required. 





IBM International Business Machine Corporation 


= mony Pome | TT enn 
a 


Result Field 


2 
2 
3 
Length |& 
a 
E 
@ 
a 





| Programmer 





Factor 1 Operation 






8 19 20 21 22 23 24 25 2 32 


MiaIluiel | || | eo 


IN 
Alciulel | | | 
alulel | | 
alltel | | 
eas 


| Iho 
| be 
| Ilo 
fet te ay 


) Figure 9-33. LOKUP with an Actual Index 


RPG CALCULATION SPECIFICATIONS 





Factor 2 





38 39 40 41 42143 44 4! 


Tr eeroe TTT 
Pl tle) TT 

bugl LT eel bl COPE 
Kwblaialy | TTT TT TT 
PPA VAN? 
KuplAiRy|s aul | | tt tt | 
PLT TE 


Form GX21-9093 
Printed in U.S.A. 


12 75 76 77 78 79 80 


P f Program 
oe > —___ Identification 


Resulting 
Indicators 


} Arithmetic | 





Comments 






2 


| 


| ie 
a ee 
fe eet 
a ae ae ee 


Arra ys 9-29 


As shown in Figure 9-34, first the compare operations are . then begins at the element number specified. The array 


performed to determine whether the value is in the first, lookup continues, one element at a time, until the search 
second, or last third of the array. The results of the com- condition is satisfied or the end of the array has been 
pare operations determine which number should be zero- _ reached, whichever occurs first. If an index field is speci- 
added into the index field, IXFLD, before the lookup is - fied, the number of the array element first satisfying the 
performed. : search condition is stored in the index field. However, if 

. the end of the array is reached and none of the elements 
See the previous Note for an explanation of the use of the satisfy the search, a 7 is placed in the index field. In any 
SETOF operation in Figure 9-34 (line 01). case, if an actual number, not an index field, is specified as 


the index, the actual index is not changed to reflect the _ 
success of the search. . | 
Determining if a Search Is Successful . 
. The way in which you determine a successful search is 


At this point, we should discuss the index field and how its whether the resulting indicator assigned has been turned on 
contents are changed as a result of the lookup operation. or off. Thus, if the resulting indicator is off and an index ~ 
Before the lookup is performed, you determine the value field had been specified, the index field should contain the 
which is to be placed in the index field. The array search value 7, the result of an unsuccessful search. If the first 


field of an array satisfied the search condition, the index 
field would also contain the value 7; however, in such a case, 
the resulting indicator would be on. 


ad 





m, RPG CALCULATION SPECIFICATIONS PrinedinUSA 
IBM International Business Machine Corporation 


1 2 
rig femme | TT PT Tp | eemonimme | an 
eer fe oh) hd LL Is rea 
. Resulting 


75 76 77 78 79 80 





JSF 
° 
fe 
oD 
2 
= 
‘Ey 


Factor 1 Operation Factor 2 Comments 


= 
° 
° 
x 
€ 
= 
mal 
sh 
ain 
8 
s 
Nn 
= 


on 
= 
o8 
ye 
yi 
o 2 
c 
So 


Oj 


Nea} 


i | 


Past Pied 


| 


Nuart 


poe a eS ee 
a ee 
ee ee 
[| AAR ORT 
| | eS Bl wT 
| | Dewy 


IF 
et | 
P| 
DOL 
pin 
up 
ai 


| AAA 





Figure 9-34. LOKUP with an Index Field 
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Referencing an Element Which Satisfies a Search 


After a successful search, you can use the data from the 
element which satisfied the condition only if the array name 
with an index field is specified in the LOKUP specifications. 
If an index field is specified, the number of the field which 
satisfied the search is stored in the index field. Therefore, 
specifying the array name with the index field in a sub- 
sequent calculation or output specification refers to the 
element which satisfied the search. 


However, if no index field is available (array name specified 
alone or with a numeric index), the number of the element 
cannot be determined and, therefore, the data cannot be 
referenced. You can only determine if one of the array 
elements does contain the data for which you searched, 
according to the on-off status of the resulting indicator. 


The ability to reference a data item which satisfies a search 
is one of the major differences between an array lookup 
and a table lookup. During a table lookup, when a field is 
found which satisfies the search, the table name alone refers 
to the data item which satisfied the search. Following a 
lookup for an array, specifying the array name alone refers 
to the entire array, rather than to any particular element. 
The only way an individual array element can be referenced 
is by specifying the array name with an index. 


Assume you wish to search an array CHG to check for 
amounts over $100. If you only want to determine if there 
are any elements containing a greater amount, the search 
can be coded as shown in Figure 9-35. If indicator 16 is on, 
indicating a successful search, you can then print a message 
stating there is a charge over $100. Otherwise, if indicator 
16 is off, you can print a message stating all charges are 
under or equal to $100. With the LOKUP specification 
shown, however, you would have no way of knowing how 
many elements or which elements satisfied the search 
condition. 
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If you wish to know which element satisfied the search or, 
perhaps, how much over $100 the amount is, the array 
lookup should be coded with an index field (Figure 9-36). 
The index field can be preset to contain the value 7, so the 
search begins at the first element of the array. If the search 
is satisfied, |X will contain the number of the first element 
over $100; and the resulting indicator will be turned on. 
The contents of 1X can then be printed to indicate which 
element satisfied the search. The actual contents of that 
element can be printed by specifying the array name with 
the index field (Figure 9-36, Output sheet). 


Searching An Array for More Than One Element 


The previous example points out an important considera- 
tion: an array LOKUP operation is completed when the 
first element is found which satisfies the search condition. 
If you wish to find all elements which satisfy the condition, 
you must code additional specifications which cause the 
program to loop back in calculations to repeat the lookup 
operation from the point where the last search was success- 
ful. 


As an example, assume your company manufactures 25 dif- 
ferent items, identified by item codes 1-25. A 25-element 
array QTY (Figure 9-37) is used to keep track of the quan- 
tity in stock of each item. The first element contains the 
quantity of item code 7, the second element contains the 
quantity of item code 2, and so on. . 
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Figure 9-36. Determining Which Array Element Satisfies the Search 
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Figure 9-37. More than One Array Element Which Satisfies the Search Condition 


100 items are to be manufactured and added to stock when- 
ever the quantity of an item falls below 25. To determine 
which items are to be manufactured, every week the QTY 
array is searched, comparing the array elements with a search 
word (MFGPT) of 25 from a data card. When a quantity is 
found to be less than 25 (search condition Low), the item 


_ code and quantity in stock are printed. 


From Figure 9-37 you can see that four items must be manu- 
factured. The specifications in Figure 9-38 will not locate 

all of the items with quantities less than 25. The lookup 
operation shown will locate only the first quantity below 

25. If only one data card (containing the search word) is 
read, the specifications are performed once. As you know, 
for every data card read, the program cycle is repeated. How- 
ever, even if several data cards with the same search word 
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Figure 9-38. Array Search Which Locates Only One Element 





Factor 2 





are read, every time the lookup is repeated, the search begins 
again at element 7 of the array. Therefore, the same array 
element satisfies the search every time, and the other three 
quantities are never found. 


To locate more than one element satisfying the same search 
condition, the LOKUP must be repeated within a single pro- 
gram cycle. Not only must the LOKUP be repeated, but the 
search must begin at the point where the previous search 
ended. You can repeat the LOKUP using the GOTO and 
TAG operations, as shown in Figure 9-39. To make sure the 
repeated search begins where the last search left off, you 
must specify the array name with an index field in the 
LOKUP specification. The contents of the index field is 
then updated after each successful search to indicate at 
which array element the next search should begin. 
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The first search should begin at element 7. Thus, as Figure 
9-39 shows, the index field |X is initially set up to contain 
the value 7. (The field is zeroed before adding 7, since you 
have no way of knowing the contents of IX at the beginning 
of the program run.) The TAG operation is not performed; 
therefore, the computer skips this specification and per- 
forms the LOKUP. 


When the first QTY element less than 25 is found, the num- 
ber of the element (04) is placed in the index field. Pro- 
viding the LOKUP was successful (33 on), a 7 is added to 
the value in the index field, to indicate at which element 
the next search should begin. The value in the index field is 
then compared to 26 to see if the entire array (25 fields) has 
been searched. If there are still array elements to be checked 
(indicator 44 on), the program branches back (GOTO) to 
perform the LOKUP again. The search would then begin 
again, only at the element following the last element which 
satisfied the search. The calculation specifications would 

be repeated over and over until all items to be manufactured 
are located and until the end of the array is reached. 


Output During an Array Search 


The specifications in Figure 9-40 search through the QTY 
array to locate more than one element. In this case, it does 
no good to search through an array unless you know what 


data was found. For this reason, each quantity less than 25 
and its related item code are printed. Following each suc- 
cessful search, the item code number (same as the number 
of the array element containing the quantity) is stored in 
the index field 1X. Thus, the field IX can be printed. The 
actual quantity which satisfied the search can be printed by 
specifying the array name with the index field in the output 
specification. 


Since the output specifications usually are not performed 
until all calculations are done, normal output would be in- 
valid since there would be an attempt to reference array 
element 26. 


In order to print each item code (field number) located in 
the array search (and its quantity), output must be done be- 
fore the contents of the index field are changed. 


You have learned that using the EXCPT operation on the 
Calculation sheet makes it possible to perform output spec- 
ifications before calculations are finished and then to return 
to finish the calculation operations. As Figure 9-40 shows, 
following a successful LOKUP, the EXCPT operation then 
causes the data placed in the index field to be printed, fol- 
lowed by the contents of the array element which satisfied 
the search. After the exception output has been performed 
(output lines identified by an E in column 15), the program 
continues with the calculation specifications by executing 
the calculation which follows the EXCPT operation. 
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Figure 9-39. Repeating a LOKUP to Locate All Array Elements Satisfying the Search Condition 
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. LOADING ARRAYS 


In the beginning of this chapter (Defining an Array), you 
) learned that arrays are divided into three types based on 
| when the array data is stored into the array. The three 
_ different times are compilation time, pre-execution time, 
and execution time. Data can be stored in any of the fol- 
lowing ways: 


@ Compilation time: keyed in on a console (keyboard) 
_ device; read from punched cards, tape, or disk source © 
library 


@ Pre-execution time: keyed in ona console device; read 
_ from punched cards, tape, or disk 


@ Execution time: Extracted from an input file on a con- 
sole device, punched cards, tape, or disk during execu- 
tion of the program 


@ Execution time: Created by calculations performed 
during the program 


IBM International Business Machine Corporation 


Compile Time Arrays 


Arrays loaded at the same time as your RPG I! source pro- 
gram are referred to as compile time arrays. The array is 
compiled along with the RPG I! source program. The array 
data actually becomes part of the object program. One 
definite advantage in creating compile time arrays is that 
you need not load separate array files into the computer 
every time you wish to run that object program. | 
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Changing Compile Time Arrays 


Temporary changes to data in a compile time array exist 
only for a particular run and are made as easily as for any 
array. Calculation specifications which have been previous- 
ly coded in the program can modify any of the array ele- 
ments. 


Making permanent changes to a compile time array requires 
recompiling the entire RPG I] source program along with the 
new or changed array input records. The object program 
produced then contains the current array data. 


Loading Compile Time Arrays 


An array to be compiled with your program should follow 
the RPG II source program (Figure 9-41). There should be 
a record immediately before the array containing ** in posi- 
tions 1-2. Position 3 must be blank but remaining positions 
may be used for comments (such as the array name). If 
more than one array is to be compiled, a ** record should 
be placed before each array. Furthermore, the compile time 
arrays must be loaded in the same order as they are described 
on the Extension sheet. The end of file record (/* in posi- 
tions 1-2) which usually comes at the end of the source pro- 
gram is then placed after the last compile time array. 





RPG I! Source Program 





Model 10 Card System Users: The source program 
and array input records as shown here are placed 
in the secondary MFCU hopper. The RPG II 
Compiler program is placed in the primary hopper. 


Figure 9-41. Arrangement of Input for Compile Time Arrays 
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Model 10 Disk System, Model 15, and Model 6 users may 
place compile time arrays in the source library following the 
source program. The same record sequence as shown in e 


f 
| 


Figure 9-41 is used. See the applicable reference manuals for _ 
your system for specific procedures. | 


' Pre-execution Time Arrays 


In general, if an array is to be permanently modified often, 
a pre-execution time array is easier to use than a compile 
time array. A pre-execution time array is not compiled with 
your RPG II source program. Instead, once the object pro- | 
gram has been loaded into the computer to be executed, the 
array is loaded separately like an input data file. The array 
is then used by the object program, rather than being a part 
of the program. 


Changing a Pre-execution Time Array 


Modifying a pre-execution time array is easier than changing 
a compile time array. Modifying the contents of the array 
permanently (whether a short array or a full array) can be 
done by inserting and deleting change records. In any event, 
only the array file is changed; there is no need to make 
changes in the RPG II object program. 


Loading Pre-execution Time Arrays \ 


Pre-execution time arrays are similar to any other input data 
files in that the RPG II object program uses the files when 
the program is executed. Unlike other data files, however, 
pre-execution time arrays are read completely before execu- 
tion of the program continues. 


The array files should be in the same order as for compile 

time arrays. All array files are to be loaded in the same order . 
as they are described on the Extension sheet.. Furthermore, 

if both pre-execution time array files and other input data 

files are to be used by a program, all arrays must be loaded 
before the data files. An end of file card (/*) must follow 


every pre-execution time array file, regardless of whether 
the array is short or full (Figure 9-42). 


Specifications for Pre-execution Time Arrays 


Since a pre-execution time array is a separate file to be used 
by the program, the entire file of array input records must 
be defined on the File Description sheet, just as any other 
file must be. Figure 9-43 shows the file description specifi- 
cations required to define a pre-execution time array input 
file. A filename, different from the array name, should be 
assigned to the entire array file (columns 7-14). A unique 
filename should be assigned because the single file may ac- 
Ratt ecco ecco TEL sith tually contain data for two arrays, if alternating format rec- 
oe Sa | hi | iD ords are used. Figure 9-43 shows a file called ARFILE, 
‘Array File cH y containing data for both ARRAYA and ARRAYB. An /in 
(sharon full) column 15 says that ARFILE is an input file. Notice 
also, that the File Designation entry (column 16) must be a 
T, to indicate that this is an array file, as well (T stands for 
either a table file or an array file). The Device entry (col- 
umns 40-46) indicates the device from which the array file 
is read (for the Model 10 Card System, the entry must be 
MFCU2). 











Model 10 Card System Users: The array files are 
loaded from the secondary MFCU hopper. The 
RPG II object program is loaded from the primary 
hopper. 


Other Systems: Array files loaded at pre-execution 
time may be loaded from console, cards, disk or tape. 


‘ 
4 Figure 9-42. Arrangement of Input for Pre-execution Time Arrays 
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Figure 9-43. Defining a Pre-execution Time Array File 


Ordinarily, if an input file is to be in a particular sequence, 
an entry (A or D) is made in column 18 of the File Descrip- 
tion sheet. When specifying a sequence for array files, how- 
ever, the sequence columns (45 and 57) on the Extension 
sheet must be used, rather than the sequence column on the 
File Description sheet. An E has been entered in column 39 
of the File Description sheet to indicate that the records in 
this array file are further.described on the Extension sheet. 


Looking at Figure 9-43, you can see that the filename as- 
signed on the File Description sheet is also entered under 
From Filename (columns 11-18) of the Extension sheet. 
This common entry tells the computer that the extension 
specifications describing ARRAYA and ARRAYEB arrays 
are associated with the ARFILE file defined on the File 
Description sheet. For compile time arrays, previously de- 
scribed, no entry is made in columns 11-18, since no file- 
name is assigned to compile time array records. 


Storing Input Data into Execution Time Arrays 


When an execution time array is defined in an extension 
specification, an array is set up in the computer, ready to 
receive array data. You have learned that the array data 
can either be generated by calculations in your program or 
be taken from an input file that your program reads. There 
is an important difference between the input file used to 
build an execution time array and the input file used to 
build a pre-execution time array (see Loading Arrays, Pre- 
execution Time Arrays). That is, the input file from which 
an execution time array is built is not a special array file 


designated by a T in column 16 of the File Description sheet. 


Therefore, the array data is not automatically loaded into 
the array at the beginning of execution time. Instead, you 
must describe the input data to be loaded into the array on 
input specifications and ensure that the necessary data is in 
the array before doing operations that use the array data. 


Fields of.array data to be read from input records must be 
‘described on the Input sheet. The input specifications in- 
‘dicate where the data is located on the record. How the ar- 

ray information is described and stored depends on three 
factors: 


1. How the array data is organized on a record. 


2. ° Whether the data for an array is contained in one or 
more records. 


3. | Which System/3 model you are using. 
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An input record containing array data can contain only data 

for that array or can contain both array data and other data 
fields to be used in the program. In either case, the array 

data is organized in one of two ways: a 


1. All array elements may occupy consecutive positions 
on the record; that is, each element immediately fol- 
lowing another with no blanks or other data between 
the elements. 


2. The array elements may be scattered on the record, in 
any order, with blanks or normal input fields placed 
between the array elements. 


The way in which the data is organized and the size of the 
array generally determines the number of input records re- 
quired to contain the array data. 


Array Data in Consecutive Positions on One Record 


If array elements are in order in consecutive positions on a 
record, describing and storing the data is very easy. All of 
the array data on the one record may be described on the. 
Input sheet as if it were a single field. Thus, only one input 
specification is necessary to indicate a name for the field 
and the columns on the record where the array data begins 
and ends (Figure 9-44). By specifying the name of the ar- 
ray as the field name, the data is automatically stored in the 
appropriate elements of the array as the input record is read. 


When you describe an input record of array data, you specify 
no entry in column 52 (Decimal Positions) of the Input sheet. 
Since the array name and characteristics have been previously 
defined on the Extension sheet, the entry in column 44 of 
the Extension sheet indicates the number of decimal posi- 
tions in each array element. 


Array Data Scattered on One Record 


When array elements are scattered on an input record, each 
field must be described separately on the Input sheet to in- 
dicate where each item of array data begins and ends. Two 
methods are available to load the data into the array: 


1. Assign a unique field name to each field of array data 
on the input record, then code calculations to move 
each data field individually into the appropriate array 
element. 


2. Assign the array name with the proper index to each 
field of array data in the input record and the array 
will be loaded automatically as the data is read. (This 
method of loading array data is not available for the fF 

‘System/3 Model 10 Card System.) : 
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Figure 9-44, Storing Data in an Array 
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Assume that a 6-field array named EMP is set up by coding 
extension specifications. The six fields of data for the array 
are scattered on a record, as shown in Figure 9-45. Addi- 
tional input information (blanks and other input fields) is 
recorded between the array fields. Furthermore, the array 
fields are not in the order in which they are to be stored. 


When you describe the array data, you must identify each 
field by a separate line of input specifications, because the 
array data is not continuous. Normal input fields can be 
described along with the array fields. Separate fields can 
be identified and stored as follows: 
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Figure 9-45. Scattered Fields of Array Data in One Input Record 
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All System/3 Models: One way to identify and store array 
data is shown in Figure 9-46. Unique field names are as- 
signed to individual fields of array data on the Input sheet. 
Once the scattered fields have been described on the Input 
sheet, each field of array data is stored in the array using a 
MOVE calculation. Since each field has a unique field name 
and must be stored in a specific array element, a separate 
move specification must be coded for each field to be 
stored. . 


The specifications which move the array data into the array 


elements should generally be specified first on the Calcula- 


tion sheet. This ensures that the data will be in the array 
when any calculations on the array (specified later on the 
Calculation sheet) are performed. 
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Figure 9-46. Loading Array Data From Scattered Fields by Assigning Unique Field Names 
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All System/3 Models (Except Model 10 Card System and Array Data Consecutive on More Than One Record (Model 


Model 15C): Figure 9-47 shows a second way to load an 10 Card System) 

‘array from scattered fields. The array name with an index 
is assigned to each field of data in the input record. Inthis . Considera case where the array data on all input records is 
way, the data is loaded directly into the array as the fields organized consecutively. Data for a 25-element array named 


are:read. No move calculations are necessary. 


- TAX is contained on two input records (Figure 9-48). The 


first record contains 19 fields, the second record, six. Each 
numeric field is five characters long. The data is organized 
on the records in the order it is to be stored in the array. 
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Figure 9-47. Loading Array Data From Scattered Fields by Means of Input Specifications 
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Figure 9-48. Loading Array Data Consecutive on More than One Record (Model 10 Card System) 
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It is important to note that when data is stored in an array 
by specifying the array name as the field name, the informa- 
tion is placed at the beginning of the array. Thus, the 95 
columns of data from this first input record are stored in 
elements 1-19 of the array (Figure 9-48). 


Although the data on the second record is also arranged 
consecutively, each element is loaded separately. The sec- 
ond record cannot be defined as a single array field and 
stored automatically in the array because the data would 

be stored at the beginning of the array, destroying the data 
previously stored at the beginning of the array. Instead, the 
data from the second record is loaded by defining the in- 
dividual fields as array elements on the Input sheet (Figure 
9-48). The data could also be loaded by assigning a unique 
fieldname to each field of array data on the second record 
and using MOVE operations to move each field to its proper 
array element. In this case, specifications would be similar 
to those for the EMP array in Figure 9-46. 


In this example, the method of defining and storing data in 
the TAX array is relatively simple. However, if there are a 
large number of data fields contained on records other than 
the first, storing the data can require a great number of 
coding lines. Suppose, for example, the TAX array consists 
of 50 fields. Three records are required to contain the data. 
The first two records contain 19 fields each; the third con- 
tains 12 fields. Storing the data using the method shown in 
Figure 9-48 requires 31 separate lines of coding to load the 
data on records two and three. Because of this, you might 
want to consider loading the array as a compile time or pre- 
execution time array, instead. 
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Array Data Consecutive on More Than One Record (Model | 
6, Model 10, Model 12 and Model 15) 


| On the Model 6, Model 10, Model 12 and Model 15, it is 
much easier to load array data that is consecutive on more 
than one input record. Consider the previous example - 
(Figure 9-48). The a‘tzy data on the second record can be 
described as a single field on these systems, because the 
MOVEA. operation code is available on these systems to 
move data from a field to an array. Figure 9-49 shows the 
coding necessary to load the TAX array when the MOVEA 
operation is used in calculations. 


Using the MOVEA operation, data that is consecutive on 
many input records can conveniently be loaded during 
program execution. See your RPG || Reference Manual for 
a complete description of the use of MOVEA. 
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@ Figure 9-49. Loading Array Data Consecutive on More Than One Record (Model 6, Model 10 Disk System, and Model 15) 
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Array Data Scattered on More Than One Record 


Regardless of how many records are used to contain array 
data, if the fields are scattered on the records, each field 
must be individually loaded into its appropriate position in 
the array. However, a separate specification is not always 
necessary for each field of data to be loaded. In some cases, 
the same specification can be used for all the records. This 
depends on whether all the input records for a single array 
are organized in the same format and whether the fields 
from different records can be assigned the same name. 


Assume that a 22-element array, named ARA, is defined. 
The data for the array is scattered on six input records, as 
shown in Figure 9-50. Although the array data is not con- 
secutive, the four fields on each of the first five records are 
in the same format on each record. The remaining two fields 
on the sixth record are in the same format as the first two 
fields on all other records. 


Since the array data follows the same organization on all 
records, describing one set of fields (Figure 9-51) actually 
describes the fields on all records, except the last. A sep- 
arate input specification should be coded to indicate that 
record 6 only contains two of the fields. (Note on the In- 
put sheet that records 1-5 are described in an OR relation- 
ship. Therefore, a specific card sequence cannot be speci- 
fied in columns 15 and 16. You can assume that the array 
input records are in sequence. Record type 1 is the first 
record read and record type 6 is the last.) 


9-46 


mo 


Ray 


Figure 9-50. Array Data Scattered on More than One Record 
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Figure 9-51. Describing One Set of Array Input Fields for Several Records 
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Because the fields on the different records have the same 


. field names, only one MOVE specification is necessary for 


each unique field name. The specification on line 07 of 
Figure 9-52, when repeated for each record, moves FLDA 
of that record to the appropriate element of the ARA array. 
Lines 09 and 10 are performed for every record except the 


fast, which does not have fields FLDC and FLDD. 


Since the fields on the input records are in the same order 
as they are to be stored in ARA, a definite pattern is estab- 
lished as to where the data is to be moved. Fields from rec- 
ord 1 are stored in array elements one through four, fields 
from record 2 in array elements 5 through 8, fields from 
record 3 in array elements 9 through 12, and so on. 


Array index fields can be used to indicate to which array 
elements that data is to be moved. For each unique field 
name, an individual index field should be set up. In this 
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Figure 9-52. Using the Same MOVE for Fields from Several Records 
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way, the values in the index fields only have to be changed 
every time another array input record is processed. When 
the first record is read, the index fields A, B, C, and D are 
initialized to 1, 2, 3, and 4, respectively, to prepare for 
moving the fields from record type 1 (Figure 9-52, lines 
01-04). After the four fields are moved, the value 4 is 
added to each of the index fields so they point to where the 
four fields on the next record should be stored (Figure 9-52, 
lines 12-15). The same calculation specifications are re- - 
peated until fields FLDA and FLDB from the sixth record 
have been moved to the last two array elements. 


Conditioning Operations Until All Array Data is Stored 


All information must be stored in an array before you can 
reference the data by specifying the array name or array 
name with an index. Thus, any specifications to load the 
data into the array must be specified before any calculations 
which use the array information. . 
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For every record of array data, RPG II goes through a com- 


plete program cycle, just as it does to process any other data - 


card. This means that input, calculation, and output speci- 
fications can be performed every time an array input record 
is processed. You want input specifications to be performed 
to describe the array record to the system and, perhaps, ‘to 
load the array data at the same time. Perhaps, calculation 
specifications which move the data from the record to the 
array should also be performed. However, if.there are still 
some array records which have not been processed (thus, 
not stored in the array), calculations and output which ref- 
erence the array must not be performed. For example, if 
only five fields of data have been loaded into a 10-element 
array, adding all elements of the array or printing all ele- 
ments will certainly not provide the results you want. 


Once the last array input record has been stored, any speci- 
fications referencing the array elements can be performed. 
Thus, you must specify a conditioning indicator (columns 
9 through 17 on Calculation sheet and columns 23 through 
31 on Output sheet) which indicates when the last array 
record has been processed. 


Lines 02 through 13 of the Calculation sheet in Figure 9-53 
are performed to move data from the six array input rec- 
ords (see Figure 9-50) into the array ARA. When the last 
record is processed (record identifying indicator 06 on), the 
two array operations on lines 16 and 17 can be performed 


- during that program cycle. Therefore, when record type 6 


has been stored, indicator 33 is set on (Figure 9-53, line 14). 
Indicator 33 (or any other indicator which is set on) can 
then condition the XFOOT and SUB operations to be per- 
formed in a program cycle. 


The record identifying fndicatpr 06 was not specified to 
condition the array operations, because 06 is on only for 
the cycle in which the sixth array record is processed. Since 
the array operations on lines 16 and 17 must be performed 
in the following program cycles also (for example, if normal 
data records follow the array records), they must be condi- 
tioned by an indicator which is on during the following 
cycles. Once indicator 33 has been set on, it remains on' 
through following program cycles, until set off (line 01) 
when another group of array records are processed. 
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‘Figure 9-53. Conditioning Operations Until All Array Data is Stored 
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Figure 9-54 shows how the array operations must be condi- 
tioned for another situation. In this case, record identifying 
indicator 06 does not set on indicator 33 because informa- 
tion (DSCNT) from data records following the array records 
must be available before the array operations can be per- 
formed (line 16). If indicator 06 caused indicator 33 to be 
set on, the array operations would be performed during the 
program cycle in which the sixth array record is stored. At 
that point, the DSCNT data is not available. Therefore, rec- 
ord identifying indicator 09 (the first type of data card fol- 
lowing the array records) sets on the conditioning indicator 
33 instead. 
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At this point, we must mention a problem which can come 
up if array elements are contained on more than one record 
(or the same record type), and the records contain normal 
input data as well as array data. Assume three cards con- 
tain the array data and ail the data must be-stored in the 
array prior to performing\any calculation or output opera- 
tions. This means the three records must be read before 
processing. As each new record (of the same record type) 
is read, the data from the previous record is destroyed, un- 
less it has been moved or stored in a special place, such as 
an array. Since normal input data (nonarray fields) from 
the first two records is no longer available once the third 
record has been read, any calculation or output specifica- 
tions which reference this input data might give incorrect 
results. 
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| Figure 9-54. Conditioning Operations Until All Array Data is Stored and Input Data is Available 
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Review 9 


In which of the following ways is an array like a table (state true or false and the 

reasons for your answer)? 

a. Each can be referenced as one group of information. 

b. Each is a continuous series of data fields (elements) stored side by side. 

c. A particular item of data can be individually referenced in either a table or an 
array. | 

d. Each is defined by coding extension specifications. 


Can one array be compared to another array to determine which is greater or less? 
State the reason for your answer. 


Explain what happens if an array (a) of 18 elements is added to an array (b/ of three 
elements, with the result placed in an array (c) of 18 elements. 


The following array (ARASIX) is to be set up during a program run: 


. Define the array on an Extension sheet. . 

. If ARASIX is multiplied by 3, what data will be placed in the result array RESARA? 
. Should the result array RESARA be defined on the Extension sheet also? 

. If so, code the necessary extension specifications to define RESARA. 

. What is accomplished by defining an array on the Extension sheet? 


onoaoage 


a. Explain what happens when an XFOOT operation is performed. 
b. If ARASIX (refer to question 3) is specified on the Calculation sheet as Factor 2 
‘of an XFOOT operation, what data would be placed in the result field? 


How does a programmer specify that an entire array is to be printed or punched (a) 
during output time in the object program cycle; (b) at end of job? 


How does a programmer specify whether an entire array or only a particular array © 
element is to be operated upon or used for output? 
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8... Data for a SALES array is recorded on a one-record input file called INFILE in the 
following format: 


Field Columns Field Columns 

Clerk1 4-10 Clerk6 51-6u 

Clerk2 11-20 - ~Clerk7 61-70 

Clerk3 21-30 Clerk8 71-80 

Clerk4 31-40 Clerk9 81-90 

Clerk5 41-50 record code 91 (not array data) 


Each of the clerk fields contains data with two dsélmnat positions. Code the specifi-: 
cations necessary to: 
a. Define the array as a pre-execution time array. 

. If necessary, describe the input record and store the ees in the SALES array. 


9. Show two ways that data from the first five fields of the following record could be 
~ stored in an execution time array named SET (15 elements, three numeric characters 
each, no decimal positions). Column 1 of the record contains a P as the record 
IGensitying code. 





10. a. Code the output specifications to print the 13th element of the array SET 
(output filename PRINT). 
b. Code the specifications to print the entire array SET at end of job (output 
Blenare PRINT). 


11. SEARCH is the name of a field containing data you wish to locate in the 6-element 
PAY array. Code the specifications to search the array to determine if the data is 
_', present. If present, print the number and contents of the array element... If more 
than one array element satisfies the search, each is to be printed. 


12. Code specifications to: 
a. Add ARA1 to ARA2 and place the result in ARAQ. 
b. Sum all elements of ARA2 and place the result in TOTAL. 
c. Print both results. | 


a, 


4 


Answers To Review 9 


1. a. False. Only one table element can be referenced at one time. 
b. True. 
c. True. 
d. True. 


2. No. An operation to be performed on an array is repeated for each element in the 
array. Therefore, a compare (COMP) operation cannot give a meaningful result for 
the entire array. The two arrays, however, could be totaled using the XFOOT 

operation and the resulting totals could be compared. 


3. The first three elements of array a would be added to the three elements of array b, 
with the three results placed in the first three elements of array c. The remaining 
15 elements of array c (result array) remain unchanged. 


4. a. Entries shown are required; no other entries should be made. The entry in 
column 44 is necessary to indicate the elements are numeric for arithmetic: 
operations. 
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Record Sequence of the Chaining File 
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: Table or i : Table or | tength | |. 
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c. Yes, all arrays to be used in a program must be defined on the Extension sheet. 
d. Entries shown are required; no other entries should be made. Length of array 
element (columns 40-42) must be 3 to contain the largest addition result. 


Extension Specifications — 


Record Sequence of the Chaining File 


Number of the Chaining Field T. 
able or 
Length 


To Filename Table or ; : Array Name | o¢ 


Array Name ’ 
Y Per Table (Alternating Entry 
Format) 


Comments 


From Filename 


or Array 


Form Type _ 
Decimal Positions 
Sequence (A/D) 





e. An area in storage sufficient to contain the array data is reserved. The actual | 
‘ array data may be stored in the array later, when input records are read or 
zy ; during calculations. 
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5. a. The XFOOT operation causes al! elements in the array specified as Factor 2 to be 
added together. The single result of the additions is placed in the result field 
specified with the XFOOT operation. 

b. The total of all elements in the ARASIX array (115) would be placed in the 
result field. 


6. a. The name of the array is specified under Field Name (columns 32 through 37) 
on the Output sheet. The filename tcolumns 7 through 14) must also be ees 
as for output of any field. 
b. The name of the output file is specified under To Filename (columns 19- 26) on 
the Extension sheet. No entry is necessary on the Output sheet. (This method 
of array output cannot be used for execution time arrays.) 


7. The array name is specified alone (on the Calculation or Output sheet) to reference 
the entire array. The array name must be followed by a comma and an index 
number or index field to reference only a particular array element. 


8. a. Extension specifications to define the array: 


Extension Specifications 
Record Sequence of the Chaining File 


Number of the Chaining Field Table or 

Length 
Array Name } o¢ 
(Alternating Entry 
Format) 


_ Table or 
Array Name 


To Filename 


Comments 


From Filename 


Decimal Positions 
Sequence (A/D) 


Decimal Positions 
Sequence (A/D) 
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b. Input specifications to describe the input record and store the data in the SALES» 


array are not necessary, since the array is automatically loaded before execution 
of the program. 


9. First method: 
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Second method: 
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b. Output of entire SET array at end of job since SET is an execution time array, 
must be done using output specifications, as shown below: 
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if SET were a compile time array or a pre-execution time array, output of the 
entire array could be accomplished by entering the output filename in To File- 
name (columns 19-26) in the extension specification for the array: 
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_- Chapter 10. Working With Data Structure 


CHAPTER 10 DESCRIBES: 


Representation of characters on cards. 

Representation of characters in storage (disk and inside the computer). 
Packed and binary data. 

Collating sequence of cc s 

Move zone operations. 


File translation. 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO: 


Describe the representation of characters and negative numbers on cards. : 
Describe the representation of characters on disk and inside sha computer | f 4 
Define byte, bit, zone portion aid digit portion. . - 

Com pare the storing of characters on cards to the storing of Rassesees in storage: : 
Identify bit combinations with numerical values. | 

Assign numerical values to zone and digit portions. 

Define unpacked decimal! format, packed decimal format, and binary format. 
Describe the hexadecimal numbering system, 

Describe the collating sequence of choratiere: 

Code specifications to change the collating sesinnen: 


Alter the structure of characters in storage by using move zone operations. 


_ Translate characters by coding the Translation Table and Alternate Collating Sheet. 


Note: You can use the review questions contained in Review 10 at the end of this 
chapter to test your comprehension of each topic in the chapter. Questions are 
grouped according to the topic to which they apply. Answers follow the review 
questions. a a a 
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CHARACTER STRUCTURE: =) 6°! 


Representation of Characters on 96-Column Cards 


Punched cards provide data the computer is to work with. 
Each of the 96 columns of a card can contain punches for a 


single character. Therefore, up to 96 characters of informa- 


tion can be represented on a single record. 


Each column of a card consists of six punch positions, 
labeled B, A, 8, 4,2, and 7, from the top of a column to 
the bottom. Characters are represented by a combination 
of from zero to six holes punched in the punch positions of 


a single column. 


Numeric Characters 


Positions 





Alphabetic Characters 


Since there are six punch positions available, the number 
and positions of the holes may be varied to form 64 dif- 
ferent punch combinations. Each unique combination of 
punches is associated with a particular character. There- 
fore, you can represent any one of 64 different characters 
in a card column (Figure 10-1). 


A card column consists of both a zone portion and a digit 


. portion. B and A are referred to as zone punch positions, 


while 8, 4, 2, and 7 are digit punch positions. The com- 


- binations of zone and digit punches make it possible to - 


separate the characters into three groups (Figure 10-1): 


@ Alphabetic letters are represented by at least one punch 
in both the zone and digit portions of a column. 


@ The 28 special characters can consist of no punches, 
only zone punches, only digit punches, or both zone 


and digit punches. ~ 


© Positive numbers are represented by holes only in the 


- .. +°: digit punch positions. The one exception is the number 


0 which is represented by a single punch in the A zone 


*-.. punch position, . «2 


Cale ee DEE SPE EEE 


Punch 
Positions 


ca Chaecurk 


Punch 
Positions 


Figure 10-1. Character Set and Punch Combinations 
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Representation of Negative Numbers CHARACTERS 


Note that positive numbers are represented only by digit - oe -1 2 -3 -4 -§ -6 7 -8 -9 _0O 

| punches. Negative numbers (-7 through -9 and -Q) can 
also be represented to the computer. However, to indicate 
that a number is negative, a column must contain both the A 
punch combination for the number and the punch com- 
bination for the minus sign. As column 7 of Figure 10-2 
shows, the 8 and 7 digit-punch positions are punched to | 4 
represent the number 9. A -9 is represented in column 12 





ox : 2 
by the same digit punches plus a hole in the B zone-punch eee 
position. : , 1 fee 
As mentioned, all 64 possible punch combinations are as- | | 
sociated with a character. Therefore, adding a B ‘zone punch Punch 
ee Position J K L M N O P Q R } 
to the punch combination of a number means the punch 
combination for any negative number is the same as the B 
punch combination already assigned to one of the 64 char- ‘ 


acters. The negative numbers -7 through -9 are represented 
by the same punch combinations as the letters J through R; 8 





| -0 has the same punch combination as the special charac- 4 
ter 
2 

Note: Although the value -0 (negative zero) is not used by +o 
itself, it can exist as a punch combination in the units 
position of a data field. 

) The RPG tI program determines whether the punch com- @ Figure 10-3. Negative Number Punch Combinations the Same as . 
bination is a letter or a number according to whether an - Punch Combinations for J-R 


entry has been made in column 52 of the input specifica- 
tions. Column 52 is used to specify the number of decimal 
positions in a field. If an entry is present, the RPG II pro- 
gram assumes any character in that field to be numeric. Ab- 
sence of an entry in column 52 tells the RPG II program 
that it is reading either a letter or a special character in an 


Negative 9 Character 
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Figure 10-2. Punches for Negative Numbers 
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alphameric field. By examining column 52, the RPG II pro- The magnetic bits inside the computer or on disk are ar- . 


gram recognizes when the 8 zone punch is associated with ranged in groups, called bytes, just as the punch positions a 
the punch combination of one of the letters J through A or on a card are arranged in groups called columns (Figure . i 
the punch combination of a negative number. 10-4). Just as each column on a card can contain a charac- 

ter, each byte in storage can also contain a character. A 
In the discussion so far, you have learned how data is re- particular combination of on and off bits in a byte represent 
corded in a form which the computer can understand. The a certain character inside the computer, just as a particular 
‘data is represented as punched holes on 96-column cards. combination of punched and unpunched positions in a col- 
Before the RPG II program can use the data, as in calcula- umn represent that character on a card. 
tions or output operations, it must store the information. 
The data is then available in computer storage whenever it Data is represented on a card, character by character; like- 
is needed during the run of a program. 7 wise, data is stored inside the computer, character by charac- 


ter. Just as you can look at a punched card and refer toa 
character by the particular column containing that charac- 
Representation of Characters in Storage ter’s punch combination, the computer can reference a 


character by the particular byte in storage which contains 
When you look at the punch area of a card, you cannot that character’s bit combination. 


immediately determine which characters are stored on the 
card. First, you have to determine which character is as- 


sociated with a particular punch combination. The punched Difference Between Character Representation on Cards 
holes, then, are the means of representing characters ona and in Storage 
card. Similarly, a character such as the letter A is not stored 
on disk or inside the computer in a form you would recog- Although there are many similarities in the way a character 
nize as the letter A. On disk or inside the computer, there is represented in storage and on a punched card, it is im- 
is also a means of representing characters. portant to note one difference. While a card column con- 
sists of six positions, a byte consists of eight positions or 
Information from each of the 96 columns of punched cards bits. Thus, within the computer, eight positions are used 
can be transferred to disk. Data from each column is stored to represent a single character, whereas only six positions — - 
in corresponding positions on disk in the form of magnetized are available on a card. 
spots. 
A byte is divided into a zone portion and a digit portion, 
Characters are represented electronically in computer storage. just as a card column is (Figure 10-5). The four digit posi- 
The storage area of the computer consists of a number of tions, in both a byte and a column, are labeled 7, 2, 4, and 
magnetic bits, which can be turned on or off by passing an 8. However, a byte contains four zone positions, whereas 


electric current through them. The exact details of how this a card column contains only two zone positions. 
is done is not important to this discussion; what is important 

is that each bit can be in either an on state or an off state. 

We use a 7 to show a bit that is on; while a O represents a bit 

that is off (Figure 10-4). 


“off” bit 
"on" bit 





Byte 1 Byte 2 Byte 3 
(Containing Bit Combination 
for a Single Character) 


Figure 10-4. Representation of Characters in Storage , 
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Figure 10-5. Correspondence Between a Byte and a Card Column 
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Since there are four digit positions in botn a byte and a 
card column, the digit portion of a byte corresponds one- 
for-one with the digit portion of that character's punch 
combination. ‘That is, if a digit punch Position is punched, 
the corresponding digit bit is set on (7) in storage. Like- 
wise a digit bit is set off (O) if the corresponding punch posi- 
tion does not contain a punch. To check this, note how the 
digit portion of the plus sign (+) character is represented on 


a card and in storage (Figure 10-6). (Note: Ampersand (&) | 


isan exception to this rule; see Figure 10-7.) 


The zone portions of a:card column and a byte do not cor- 


respond one-to-one, however. This is because there are four | 


zone bits in storage for each character, while there are only 
two zone positions in acard column. Looking at Figure 
10-6 again, you can see that even though A and 8 punch 
positions contain punches for the pilus sign character, the 

2 and 1 zone bits in storage are not on. _ 


Punch 
Position § B.. A 8&8 4 Qe ce Sh 
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Zone 
Portion 


Figure 10-6. Similarity in Digit Portion of Byte and Card Column 
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Since the zone portions differ, a translation takes place 


when a card is read and the data (characters) is stored inside 


the computer. The machine reads the punch combination 
on the card and electronically produces the appropriate bit 
combinations in storage. Such translations (shown in Fig- 
ure 10-7) are automatic; therefore, you need not be con: © 


cerned with how the computer knows which bits to turn on 


and off. 


When programming in RPG II, however, you do have to be 
concerned with zones and digits as they are represented in- 
side the computer.:: The division of the’ card column into 
zone and digit portions is only for convenience. 


On the Input sheet, you can specify record identification 


. codes. If you choose to use only the zone portion ofa | 


character, you will be using the zone positions as they are 
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the zone of a $ character in column 7 is to turn on result- 
ing indicator 21. If an input record is read with the charac- 
ter J in column 7, indicator 21 will not turn on. Even 
though the card zone punches for $ and J are the same (both 
have the B zone punched), the bit combinations in storage 
for the $ and J do not have identical zone portions (Figure 
10-8). 
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Figure 10-8. Difference in Zone Portions of a Byte and a Card Column 
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There are exceptions which should be noted in specifying 
that the zones of characters be used to identify records. 
According to Figure 10-9, the zone of the letter J is used 

to identify record type 01, while the zone of a minus sign 

is used to identify record type 02. Recorded on cards, both 
characters have a B zone punch. However, inside the com- 
puter, their zone representations differ. 


Although the zones differ, the RPG II program considers 
the two the same. Thus, a card with a minus punched might 
turn on either the 01 or 02 indicator. Likewise, a card with 


the letter J could turn on either indicator. 


Similarly, the zone of the character b/ank is treated the 
same as the zone of 0 through 9. Also, the zone of & 
(ampersand) is treated the same as the zones of the letters 
A through |. To avoid confusion, you should not specify 
both (zones of the characters J and -; blank and 0-9; & and 
A-|) for identification of record types which are to be used. 
in the same program. 


Figure 10-10 shows the groups of characters that have 
zones that test as equal for purposes of record identifica- 
tion and the TESTZ operation. Notice that these group- 
ings are different from the groupings of characters for 
purposes of collating sequence by zone (Figure 10-28). 
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Figure 10-9. Exception: Zone Representation Considered the Same 
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Consider another example which points out the difference 
in how negative numbers are stored and how you may think 
they are stored. The minus sign alone is represented ona 
card and in storage as shown in Figure 10-11, insert A. 
Only the zone portion of the card contains a punch. Fig- 
ure 10-11, insert B, shows how a positive 5 is represented 
on a card and in storage. !n this case, only the digit portion 
of the card contains punches. Note Figure 10-11, insert C, 
for the punch and bit combinations which represent a -5. 


When checking the cards you can see that the digit punches 
for the positive 5 and the negative 5 are the same. Further- 
more, the digit bits in storage for the two characters are also 
the same. The zone punch for -5 is the same as the zone 
punch for the minus sign character. However, the zone bits 
in storage for the two characters are not the same. There- 
fore, you should not always assume that, in storage, the 
zone bits for a negative number would be identical to the 
zone bits for the minus sign (Figure 10-11). 


The reason is that the computer checks the entire punch 
combination (both zone and digit portions) of a column to 
determine which zone bits are to be on or off. Since the 
entire punch combinations (not only zone punches) for the 
minus character and the negative 5 are different, their zone 
bits in storage are also different. 


Page of GC21-7567-2 
Issued 24 May 1976 
By TNL: GN21-5389 


A conclusion can be drawn from the previous examples: 


~ each unique punch combination is associated with a dif- 


ferent bit combination. Of course, in discussing negative 
numbers before, we stated that the punch combinations of 
-7 through -9 and -0 are the same as the punches for the 
letters J through A and . Thus, the bit combinations 
for the negative numbers are also the same as those for J 
through A. 


Consider again the number of positions available to repres- 
ent a character. A characteristic of codes involving different 
combinations (such as bits on and off or punches) is that the 
greater the number of positions available to represent any 
one combination, the greater the number of combinations 
that are possible. As mentioned, with six punch positions, 
64 unique punch combinations can be made, and, therefore, 
64 different characters can be represented on a card. With 
eight bits (positions), 256 unique combinations of on-off 
bits can be created and, therefore, 256 different characters 
could be represented inside the computer. However, you 
only need 64 characters to program the computer; there- 
fore, only 64 of its 256 bit combinations are associated with 
a printable character. 
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Representation of Minus (-) Character Representation of “5” Character (Positive) 
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Figure 10-11. Representation of a Negative Number 
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Identifying Bit Combinations with Numerical Values. 


Each unique combination of eight bits can be associated 
with a numerical value. Before discussing how the numerical 
value is determined for a character, perhaps first you would 
like to know why numerical values are assigned. 


As mentioned before, data can be represented on punched 


cards. Actually, after reading a card, the computer does not 
immediately determine what character is punched. It can, 
however, distinguish one punch combination from another | 
punch combination. Furthermore, the particular combina- 
tion of punches indicates to the computer which bits should 
be set on and off to represent that punch combination in- 
side the machine. At this point, the representation on the 
card is just a particular group of punches and the representa- 
tion in storage is merely a particular combination of on and 
off bits. . 


To use the byte of data for output, the computer must 
know what character to punch or print. This is done by 
associating a numerical value with each unique bit com- 
bination. The computer automatically knows that a certain 
value is related to a particular character, such as the value 
209 indicates the character J. 


Consider how a numerical value and how the character are 
determined. Each of the eight bits in a byte are assigned a 


’ number. The values begin with 7 for the 7 bit and are 


doubled for each of the next bits (Figure 10-12). By add- 
ing.only the numbers which correspond to bits which are 
on (7), a numerical value is obtained for a byte. As Figure 
10-12 shows, first the punch combination (for the charac- 
ter F) in column 7 is translated into the bit combination in 
storage. The bits on result in a numerical value of 198, 
which the computer associates with the character F. 


Any difference in the bit combination results in a differ- 
ence in numerical value. Therefore, every character is as- 
sociated with a different numerical value. The greatest 
numerical value which can be associated with a bit combina- 
tion is 255 (all eight bits on), while the lowest numerical 
value is O (all eight bits off). This results in a total of 256 
possible numerical values. Only 64 different characters can 


- be represented on a 96 column card; therefore, we are con- _ 
cerned with only 64 of the different numerical values. How- 


ever, as Figure 10-13 shows, the 64 numerical values associ- 
ated with the characters can range anywhere from 0 through 
255. The numerical values missing from the chart are not 
related to any printable character. 
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One Byte in Storage 
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Figure 10-12. Determining a Numerical Value for a Character 
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Figure 10-13 (Part 1 of 3). Numerical Values Associated with Characters 
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Figure 10-13 (Part 2 of 3). Numerical Values Associated with Characters 
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Bit Numerical 


Assigning Numerical Values to Zone and Digit Portions 


Combination }. Value | Character an . ‘ : . ‘ 
repo cl een You have seen how a single numerical value is determined \ 
for a combination of eight bits. The numerical value of a 
character in storage can also be expressed as a pair of num- 
bers, rather than a single value. One number designates . 
the value of only the four zone bits; the other number 
represents the value of the four digit bits. 
You may be wondering why a character would ever be as- 
sociated with two paired numbers, since it can be associ- 
ated with just a single number. In certain jobs, you may — 
79077000 be concerned with only the digit portion or only the zone . 
71011001 portion of a character. For example, if records within a 
11011010 Y 28. | group are to be sequence checked only on the basis of the 
11011011 | 219. zone of a character, the computer must look at only the 
11011100 | 220 zone bits and determine a numerical value for the zone por- 
Te = tion alone in order to make the comparison. Also, if you 
11011111 293 want to alter the collating sequence or translate a file, both 
11100000. | 224 ~*'| to be discussed later, you must know the separate values 
11100001 | 225 for the zone and digit portions of a character. 
11100010 | S226” | 
11100100 Determining separate zone and digit values is similar to de- 
11100101 999 | termining a single value for an entire bit combination; that 
11100110 | 230 | is, values are assigned to each of the bit positions. The 
11100111 ) 231 values which correspond to on bits (7) are then added to 
11101000, [232 obtain a value. 
11101001 [233 | | - 
ai a — 334 To determine separate values, the zone and digit portions \ 
11101100 | 236i are each treated as separate 4-bit combinations. The four 
11101101 < bits in each portion are assigned the-values 7, 2, 4, and8& 
11101110 (Figure 10-14). The rightmost zone and digit bits each have 
17101111 the value 7; while the leftmost bits in each portion are as- 
11110000 , ; 
11110001 signed the value 8. A value for the zone portion of a byte 
11110010 is determined by adding only the values corresponding to 
11110011 zone bits which are on (7). Likewise, a digit value is ob- 


tained by considering only digit bits which are on. | 





11111001 © 
11111010 Zone Digit 
11111011 
“ 1010100114 
11111111 
Bit @ 421 : 842 1 
Assigned Bea ag Ub ge ae 
Value | 


Figure 10-13 (Part 3 of 3). Numerical Values Associated with Characters 


Figure 10-14. Assigning Values for Zone and Digit Portions of a 
Character 
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As Figure 10-15, insert A, shows, the bit combination for 
the slash (/) character produces a zone value of 6 and a digit 
value of 1. Putting the two values together, the entire char- 
acter can be expressed as the value 61. Note, however, that 
this is not the same as the numerical value 61 in our decimal 
numbering system. If we were to determine a numerical 
value for the entire 8-bit combination, we would obtain the 
value 97 (Figure 10-15, insert B). 


As mentioned before, with eight bits or positions in a byte, 
256 different 8-bit combinations can be formed. The 256 
combinations can be associated with the numerical values 
0-255 (Figure 10-16, insert A). If either the zone or digit 
portion are considered separately, however, only four bits 
or positions are available. Therefore, a maximum of 16 dif- 
ferent 4-bit combinations can be represented in either the 
zone or digit portion of a byte. The 16 zone or digit com- 
binations can be associated with the values 0 through 15 
(Figure 10-16, insert B). 


The value obtained for a zone or digit bit combination is 
referred to as hexadecimal number. Hex means 6, while 
decimal referes to 10. Hexadecimal, then, means 6 + 10, or 
16. A hexadecimal number can be any one of 16 possible 


VALUE BY ZONE AND DIGIT 


Zone Digit 


. ee t 
Bit Combination 
for '/"" Character O41 ie a 


Bit 8 4 2 1 8 4 2 1 
Values For 

VON" Bits on 2 a 
| 

| Digit Value 1 


(A) Zone Value 6 


Bit Combination | 
For "/“‘ Character 1 1 0 | 0 0 0 1 
Bit 8 4 2 1 8 4 2 1 
Values For 64 + 32 eh 
“ON” Bits 


Value 97 


) Figure 10-15. Difference in Value of Entire Character and Value 
of Zone and Digit Portions of Character 


values (0-15). Putting the two hexadecimal numbers for 
the zone and digit portions together gives a hexadecimal 
value for the entire character. 67 is the hexadecimal value 
for the / character. Keep in mind that this hexadecimal 
value is actually two separate values, one for the zone and 
one for the digit portion. 


All of the 256 possible 8-bit combinations can be repre- 
sented by a hexadecimal value; that is, two hexadecimal 
numbers. However, each hexadecimal number can take up 


_only one position. If a zone portion has the value 15 and 


a digit portion has the value 12, the hexadecimal value for 
the character cannot be expressed as 1512. Consequently, 
a zone or digit portion whose numerical value is 10 or 
greater (2-position number) must be represented in a slight- 
ly different form. This is done by assigning a single letter 
as a substitute for the number. The letters A through F 
serve as the hexadecimal forms of the values 10 through 15 
as shown in Figure 10-17. 


® 


DETERMINING NUMERICAL VALUE FOR ENTIRE BYTE 


Bt °° 8 42 1 8 4 2 #1 
Value Assigned 
To Bit 128 64 32 16 8 4 2 1 
Maximum 128+644+32+16 + 8+44+2+4+1= 255 
Numerical 
Value 





DETERMINING NUMERICAL VALUE FOR ZONE OR DIGIT 
ZONE DIGIT 


Bit 8 4 2 1 8 4 2 1 
Value Assigned 
To Bit 8 4 2 1 8 4 2 1 


| 
| 
| 
| 
| 
| 
8+44+2+1=16 | 8+44+24+1=15 


Maximum Numerical 
Value For Digit Bits 


Maximum Numerical 


| 
Value For Zone Bits 


Figure 10-16. Maximum Values for Entire Character and for Zone 
and Digit Portions 


Working With Data Structure 10-17 


| 
i 
iL 


Hexadecimal Numerical 
Value Value 








Character 
Number Value Blank | 0 
Pe 
0 0 \ 
1 1 Se 
2 2 
3 3 
4 4 
5 5 
6 6 
7 7 
8 8 
9 9 
10 A 
11 B 
12 Cc 
13 D 
“14 E 
15 F 


Figure 10-17. Hexadecimal Values of Numbers 0-15 


An 8-bit combination with a zone value of 15 and a digit 
value of 12 is expressed as having a hexadecimal value of — 
FC. Because the complete numbering series is composed 
of numbers 0 through 9 followed by letters A through F, = Se 
a hexadecimal value for the zone and digit portion of an 
8-bit combination can appear as a pair of numbers (61), a 
letter and a number. (C4, 4F), or a pair of letters (DB). 


Since zone and digit values are determined separately, a 
single combination of eight bits can have the same hexa- 
decimal number for both the zone and digit portion. Thus, 
11, 22, 33, AA, and other such values represent 8-bit com- 
binations which have the same bits on in both their zone 
and digit portions. 


Entirely different 8-bit combinations can have identical 
zone hexadecimal numbers or identical digit hexadecimal 
numbers, but not both. That is, the zone portion of one 
character can contain the same bits on and off as the zone 
portion of another character. In such a case, the identical 
zone bit combinations would give identical zone hexa- 
decimal values. However, if they are different characters 
and the zone values are identical, the digit bits and, thus, 
the digit values, must differ. This is because no two charac- 
ters can have the same 8-bit combination. 


Figure 10-18 shows the hexadecimal values associated with 
the 64 printable characters the computer recognizes. The 
hexadecimal values are in sequence just as the regular num- 
erical values are. Furthermore, the hexadecimal value as- 
sociated with a character is equivalent to the numerical 
value associated with that character. However, there is no 
need for you to be able to translate back and forth between 
numerical values and hexadecimal values. If you must use 
a character’s hexadecimal viaue in your programming, you 
can refer to the chart showing the appropriate value. 


ns 


Figure 10-18. Hexadecimal Values Associated with Characters 
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Saving Disk Storage Space 


As you have learned, each byte of storage, whether on disk 
or in the computer, can contain one character. That char- 
acter can be a decimal number or an alphabetic or special 
character. The format of the characters is known as un- | 
packed decimal format. Each byte of storage is divided into 
a 4-bit zone and a 4-bit digit part. Figure 10-19 shows the 
unpacked decimal format. 


The zone part of the low-order (rightmost) byte indicates 
whether the decimal number is positive or negative. In un- 
packed decimal format, the zone part is included for each 
digit ina decimal number; however, only the zone over the 
low-order digit serves as the sign. The low-order digit is the 
only digit which makes use of the zone portion. Figure 
10-20 shows the unpacked decimal format for decimal num- 
ber 9,269. a 4 


Packed Decimal Format. 


In packed decimal format means that one byte of storage 
can contain two decimal numbers. A decimal number will 
occupy the zone portion which is unused in unpacked deci- 
mal format. This format allows you to put almost twice as 
much data into a byte as you can using the unpacked deci- 
mal format. ae . 


‘The low-order byte in packed decimal format is also divided 


into two 4-bit parts. Each byte, except the low-order byte, 
contains one decimal digit in each 4-bit part. The low-order 
byte contains a decimal digit in the leftmost 4-bit part (bits 
0-3) and the sign of the decimal field in the rightmost 4-bit 
part (bits 4-7). Figure 10-21 shows packed decimal format. 






1 Byte 


Figure 10-19. Unpacked Decimal Format 
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Sign 





_ Figure 10-20. Unpacked Format of Decimal Number 9,269 
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The sign part of the low-order byte is used to indicate 
whether the numeric value represented in the digit parts is 
positive or negative. Compare how the decimal number — 
9,269 is represented in packed decimal format (Figure 
10-22) with its unpacked representation (Figure 10-20). 





Figure 10-21, Packed Decimal Format 


Positive 
_ Sign 


0000 1001 | 0010 0110 
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‘Figure 10-22. Packed Format of Decimal Number 9,269 






1101 = Minus sign 
1111 = Plus sign 
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You can specify packed input, output, table, or array fields: 


@ Packed input fields. Enter a P in column 43 of the Input 
sheet. This causes the data to be unpacked before it is 
stored. 


@ Packed output fields. Enter a P in column 44 of the 
Output-Format sheet. This causes the data to be packed 
before it is written out. 


@ Packed table or array fields. Enter a P in column 43 and/ 
or 55 of the Extension sheet. The data will be unpacked 
before it is stored. Packed tables or arrays are allowed © 
only at pre-execution time. 


Since data must be represented in unpacked decimal format 
once it is inside the computer, you must give the RPG pro- 
gram an indication when input fields are in a different for- 
mat. 


Because data must be represented in unpacked decimal for- 
mat before it can be processed, unpacked decimal fields 
may be stored on disk to eliminate converting the fields 
from packed to unpacked format during input. However, 
storing unpacked fields on disk requires more space than — 
storing packed fields. 


Binary Format 


You can save even more disk space than in packed decimal 
format by storing numeric data in binary format. \n binary 
format, each numeric field on disk must be either two or 
four bytes long. Each two-byte binary field can contain a 
value equivalent to four decimal places; each four-byte 
binary field can contain a value equivalent to nine decimal 
places. In other words, a numeric value in binary format 
occupies approximately half as many bytes of disk storage 
as the equivalent value in unpacked decimal format. 


Positive 


Sign 


\ 
; 0 


1} 256 ; 128 


18192 | 4096 | 2048 ! 1024 | 512 


* 


Each two-byte binary field consists of a sign bit followed 
by a 15-bit numeric value. This value can be as large as 
9,999. When a two-byte binary field from disk storage is 
read into the computer, the RPG II program converts it to 
a four-byte unpacked decimal field. Figure 10-23 shows a 
two-byte field in binary format. 


Figure 10-23. Two-Byte Field in Binary Format 


Each four byte binary field consists of a sign bit followed 
by a 31-bit numeric value. This value can be as large as 
999,999,999. When a four-byte binary field from disk 
storage is read into the computer, the RPG II program con- 
verts it to a nine-byte unpacked decimal field. A four-byte 
binary field is shown in Figure 10-24. 


Figure 10-24. Four-Byte Field in Binary Format 


In each case, the sign portion of the high-order byte (left- 
most) is used to indicate whether the numeric value is . 
positive or negative. Notice that in the binary format the 
zone portion of the decimal number is not given. Compare 
how the decimal number 9,269 is represented in binary 
format (Figure 10-25) with its packed and unpacked repre- 
sentation (Figure 10-20 and 10-22). 


The numeric value for each binary byte is obtained by adding the numbers which correspond to the bits that are on. 


(Bits that are on are represented as 1’s.) The sign bit is not included in the value of the number. The bit to the right 
of the sign bit is always 0, because the maximum value of a two-byte binary field is 9,999. 


Figure 10-25, Binary Format of Decimal Number 9,269 
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Since data must be represented in unpacked decimal for- 
mat when it is inside the computer, you must indicate to 
the RPG II program when fields are in another format. 
You can specify binary input, output, table, or array fields: 


@ Binary input fields. Enter a B in column 43 of the Input 
sheet. The data is then converted into decimal before it 
is stored. 


@ Binary output fields. Enter a 8B in column 44 of the 
Output-Format sheet. The data is then converted into — 
binary before it is stored. 


@ Binary table or array fields. Enter a B in column 43 
and/or 55 of the Extension sheet. The data will be con-. 
_ verted to decimal before it is stored. Binary tables or 
arrays are allowed only at pre-execution time. 


COLLATING SEQUENCE OF CHARACTERS 


To perform data processing applications efficiently, you 


usually organize your information in some order or sequence. 


Imagine trying to locate a person's phone number if the. 
names in a telephone book were not in alphabetical order. 
Of course, before using this order or sequence, you must 
know what it is. Through the learning process, you know 
that alphabetical order means that A comes before B, B 
before C, and so on. Likewise, in numerical sequence, 7 is 
less than 2, 2 less than 3, and so on. 


In most of your data processing applications, the computer 
must be able to recognize an order or sequence of data. For 
example, if you instruct the computer to sequence check a 
file according to an alphabetic department code on each 
record, it must be able to determine if the department T 
record should appear before the department X record, or 
vice versa. In another instruction, perhaps the computer is 
to compare two quantities, such as 3 and 8, and turn on an 
indicator if the first quantity is less than the second quan- 
tity. The computer must determine if 3 is less than 8 or if 
8 is less than 3. : | 


- The previous two tasks would be easy for you to perform 


because, through memorization or habit, you know the 
natural order of the alphabetic characters A through Z and 
the numbers 0 through 9. However, a computer has not 
memorized such orders. For the computer to perform these 


tasks, an order or sequence of characters must be established. 


To further point out the need for a set order of characters, | 
assume the computer must check to make sure records in a 
file are in proper order according to a department field. 
Some department codes are alphabetic, as department A; 
while some department codes are numbers, such as depart- 
ment 8. Should the numeric department records appear be- 
fore the alphabetic department records, or vice versa? It is 
likely that the answer would depend on who is asked. How- 
ever, for efficient data processing, you certainly do not want 
records sorted one way one time and another way the next 
time. Thus, the computer must use one set order of charac- 
ters. 


Every character recognized by the computer must hold a 

certain position in this order in relation to the position of 
the rest of the characters. Such an order is referred to as a 
collating sequence of characters. By definition, to collate 
means to arrange or verify that data appears in proper order ~ 
or sequence. | 


There can be any number of collating sequences. The se- 
quence used depends on the particular order in which char- 
acters are to be recognized. In any case, the computer , 
should use only one collating sequence at a time. 


The standard collating sequence of 64 characters is shown 
in Figure 10-26. The blank, which is the first character, is 


‘considered as the lowest in. the sequence while the number 
’ Q9 the last character, is the highest in the sequence. Note 


that all of the special characters, except the } (brace), are 
first in this sequence, followed by the alphabetic characters . 
A through Z in their natural order, and then the numbers 0 
through 9 in their natural order. The only character which 
you might not expect to be in its position is the which 
comes between the letters / and J. 


This collating sequence is the order used by the computer 
for the purpose of sorting cards, comparing numbers to de- 
termine which is greater or less, checking the sequence of 
records in a file, and matching records from two files to de- 
termine which record should be processed next. According 
to the collating sequence, the computer compares two char- 
acters to determine if one comes before or after the other, 
or is less than or greater than the other.. Of course, you 
specify which characters (or: fields of characters) are to be 
compared. . ee 
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For sorting, sequence checking, and matching, you can 
specify an ascending or descending collating sequence. For 
example, if records are to be in ascending sequence, the 
characters being checked should be in the order shown in 
Figure 10-26. That is, a card with a blank should come be- 
fore a card with the letter K. (The blank character is lower 
in sequence than the letter K.) Likewise, a card with the 
letter K should come before any records containing one of 
the numbers O through 9. If you specify descending se- 
quence, the computer compares to make sure they are in 
the opposite order, the characters higher in sequence coming 
first. 


As mentioned, a computer cannot memorize the order of 
characters; it must use another method for remembering 
the collating sequence. To do this, it uses the values associ- 
ated with characters to determine each character’s relation 
to another character in the sequence. —— 


In a previous discussion, a value is calculated for each bit 
combination in storage. The value can be thought of as a 

_ single numerical value for the entire 8-bit combination or 

as a 2-digit hexadecimal value, which is actually one hexa- 
decimal number for each 4-bit combination (zone and digit). 
A hexadecimal value is another way of representing a num- 
erical value. 


Once a value is calculated, the computer uses it to deter- 
mine which character is represented. Thus, the numerical 
value 193 (same as hexadecimal value C1) is associated with 
the character A while the numerical value 243 (hexadecimal 
value F3) is associated with the numeric character 3. Per- 
haps you wonder why a particular value, such as 193 (C1) 

- is related to the letter A, rather than a different value. 


The values associated with the 64 characters were originally 
assigned such that the natural sequence of the values corres- 
ponds with the positions characters are to hold within the 
collating sequence. For example, the character A is associ- 
ated with value 193 (hexadecimal C1), B with 194 (C2), C 
with 195 (C3), and so on. Just as A is lower than B and B 

- is lower than C in the collating sequence, 193 (C1) is less 
than 194 (C2), and 194 (C2) is less than 195 (C3). 
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Figure 10-26. Standard Collating Sequence 
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Figure 10-27 shows the 256 possible bit combinations, their 
numerical! and hexadecimal values, and the characters associ- 
ated with each. In this list of bit combinations, the numer- 
ical values are in order from O through 255 (hexadecimal 
values 00 through FF), and the associated characters are in 
the standard ascending collating sequence. 
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As you can readily see, the value associated with a charac- 
ter does not always immediately follow the value associated 
with the previous character in the sequence. For example, 
the character S follows the character A in the collating se- 
quence of characters. However, the numerical value of S, 
226 (hexadecimal E2), does not immediately follow the 
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Figure 10-27 (Part 1 of 3). Characters and Values Associated with the 256 Bit Combinations 
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numerical value of R, 217 (hexadecimal D9). The reason 
for the gap is because the bit combinations with the numer- 
ical values 218 through 225 are not associated with any of 
the 64 printable characters. Regardless, the comiputer de- 
termines that R is lower in sequence than (comes before) S 
because the value of R (217 or hexadecimal DQ) is less than 
the value of S (226 or hexadecimal E2). 
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Figure 10-27 (Part 3 of 3). Characters and Values Associated with 
the 256 Bit Combinations 





Collating By Zone Or Digit 


You learned from a previous discussion that the zone and 
digit portions of characters can be treated as separate and 
distinct groups of four bits, each with its own hexadecimal 
number. 


Different characters may have identical zone bits or iden- 
tical digit bits, but not both. Consequently, different char- 
acters may be associated with the same zone hexadecimal 
number of the same digit hexadecimal number but not both. 
As an example, the character A is associated with the value 
C1, B is associated with C2, and K is associated with D2. A 
has the same zone value (C) as B, while K has the same digit 
value (2) as B. However, B is the only character. with both 

a zone value of C and a digit value of 2. 


In most data processing tasks, the computer uses entire | 
characters or the values of those characters to make com- 
parisons, to determine which is greater or less, and so on. 
However, for certain purposes, such as sorting cards, you 
may wish to have the computer check only the zone or 
only the digit portion of characters. In such a case, the 
computer must use a collating sequence based on Zone or 
digit values rather than the standard collating sequence 
based on the entire value. 


If the computer uses a collating sequence based on the zone 
portions of characters, any differences in the digit bits are 
ignored. Only the value of the zone bits are considered. 
The reverse occurs if a collating sequence based on the digit 
portions of characters is to be used. 


The fact that certain characters have the same zone or digit 
values can be used to group characters within a collating se- 
quence. On the basis of zone values, the 64 printable char- 
acters are divided into eight groups (Figure 10-28). The 
zone bits (and values) are identical for all characters within 
agroup. If collating is to be on the basis of digit values, the 
characters can be divided into 16 groups (Figure 10-29). In 
such a case, digit bits (and values) are identical for all char- 
acters within a particular group. 


Using the standard collating sequence, the computer con- 
siders each character to hold a specific position in the se- 
quence. Therefore, no two characters can be considered 
equal; one must come before another or be less than an- 
other character. 2 

On the other hand, using a collating sequence based on zones 
or digits, one group of characters follows another group of 
characters. The characters within a group can occupy any 
position within that group. Thus, there is an order of groups 
but no particular order of characters within a group. 
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Figure 10-28. Collating Sequence by Zone 
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Figure 10-29. Collating Sequence by Digit 
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Note that in the collating sequence by zone shown in Fig- 
ure 10-28, any character in group 5 is considered Jower in 
sequence than any character in group 6. If records are 
sorted in ascending order by zone, a record with the letter 
D (group 5) comes before a record with the letter N (group 
6). 


Now consider a case in which characters from the same zone 
group are to be compared. Assume one record contains the 
letter D (group 5) and the next record contains the letter F 
(group 5). Which should be sorted first according to a col- 
lating sequence based on zones? Since the computer ignores 
the digit bits of each character, they are considered equal 
because they both have the same zone value. Therefore, no 
one character must come earlier in the sequence than an- 
other character from the same group. The sequence of the 
characters is the same order in which the records are read. 
Thus, if the D card is read first by a sort program, the 

D record comes before the F record. On the other hand, 

if the F card is read first, the F record comes before the 

D record. In either case, the records are in proper sequence 
based on zones. | 


ALTERING THE COLLATING SEQUENCE 


A collating sequence is the order in which characters are ar- 
ranged. As you know, all characters are associated with dif- 
ferent numerical values in order that the computer may 
recognize them. The sequence of numerical values (ascend- 
ing or descending sequence) determines the order in which . 
characters associated with the values are recognized. 


The association of a particular character with a numerical 
value is an arbitrary decision. Thus, the collating sequence 
itself is arbitrary. System/3 is programmed to expect the 
collating sequence discussed previously in the section Co/- 
lating Sequence of Characters. This does not mean, how- 
ever, that you must always use this sequence. You can 
change it and there may be times when you desire to do so. 
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For example, you may want alphabetic characters to follow 
the numbers instead of preceding them. Suppose that a com- 
pany originally started with a few departments. The depart- | 
ments were assigned numbers from 01-99. Two columns Ss 
were devoted to department numbers in various records. 

The company expanded and departments increased. Soon 
there were more than 99 departments. To avoid having to 
change the department field from two to three characters 

in all records, the manager decided to use the letters of the 
alphabet to represent department numbers: 99, AO, Al, 

etc. In this case, A must follow the number 9 in the se- 

quence. Thus it is necessary to alter the collating sequence 

so that numbers come before alphabetic characters. 


There can be other reasons than the one just explained for 
altering the collating sequence. Your language may de- 
mand that you have characters such as A, A’, O, E, E’in- 
cluded in the alphabetic sequence (A, A, B). Since the 64 
graphics do not include these characters, other seldom used 
characters can be substituted for them and repositioned in 
the collating sequence. For example, a number-symbol (#) 
repositioned between the letters A and B can substitute for 
an A; an at-symbol (@) repositioned betwedt O and P sub- 
stitutes for an O. 


These are only a few reasons for altering the collating se- 
quence. You may have others. Just remember that you 
can alter the collating sequence in any way that fits your 2 
needs. . : 


Specifying Changes in Collating Sequence 


To change the collating sequence, you must associate char- 
acters with different numerical values. The following sec- 
tions will explain how this is done.  % 
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Forms For Altering the Collating Sequence 


Figure 10-30 illustrates two forms on which you must 
specify changes to the collating sequence. One form is the 
RPG I! Control Card and File Description sheet; the other 
is the Translation Table and Alternate Collating Sequence 
Coding Sheet which is used for listing the actual changes in 
sequence. Both forms are used in conjunction with the 
RPG Hi Input, Output and Calculation sheets. 


A letter S entered in column 26 of the RPG II control card 
notifies the program that additional information will be 
furnished to the program so that the collating sequence 
can be altered. All other columns contain the information 
that must normally be entered to process a job. 


The Alternate Collating Sequence Coding Sheet lists 256 bit 
combinations along with their hexadecimal numerical values. 
As you learned from discussions of character structure, hexa- 
decimal values are written in the form of two character _ 
values. One value represents the numerical value of the char- 
acter’s zone; the other represents the numerical value of the 
character’s digit. The 64 printable graphics are listed beside 
the bit combinations and numerical values with which they 
are associated. 


Coding a Change in Sequence 


Each change in the collating sequence is specified in the 
Replaced By column on the coding sheet. In this column, 
place the hexadecimal value of the graphic whose position 
in the normal sequence is to be changed. The character 
corresponding to the hexadecimal value entered in the 
Replaced By column replaces the character which is present- 
ly associated with the bit combination shown on the same 
line. 


Figure 10-31 illustrates entries made to change the normal 
collating sequence. Hexadecimal values entered on the sec- 
ond and third lines of the sample coding sheet reverse the 
order in which the numbers 7 and 2 are recognized by the 
computer. 


Numerical values entered on the second line of the sample 
specify that the number 2 (hexadecimal value F2) replaces 
the number 7. In other words, in the new sequence the 
number 2 is associated with the value F1 instead of the 
number 7. Hexadecimal values on the third line specify that 
the number 7 (hexadecimal value F1) replaces the number 
2. These two specification lines cause 2 to come before 7 

in the collating sequence (0, 2, 7, 3). 


10-30 






‘Character Associated Numerical! Value of 
with Bit Combination the Replacement Character 


| ye. 


System/3 Replaced 
Graphic by 


‘110000 | o | ro | 
41110001 ei Tres 
11110010 


Numerical! Value 


of Bit Combination / / 2 Replaces 1 


8-Position Bit Combinations i eblabes 2 


Figure 10-31. Explanation of Alternate Collating Sequence Sheet 


Effect of the Coded Change in Sequence 


Any alternate collating sequence you specify is used tem- 
porarily. It is used only for the program which contains 
the alternate collating sequence specifications. Even more 
specifically, it is used in that program for operations which. 
involve sequencing, such as checking sequence of records, 
comparing fields, or matching records. 


You may think, according to specifications in Figure 10-31, 
that the character 2 read into the computer is a/ways re- 
placed by a 1. This is not true. The computer associates 
characters with the values you specify only before sequen- 
cing operations involving: 


1. Compare operations on alphameric fields. 


2. Matching or sequence checking match fields. 


Ne 


How does the computer keep track of the collating sequence 
‘ to use? :The computer keeps all your instructions for alter- 


ing the sequence in storage. The area in storage which holds 
this information may be pictured as shown in Figure 10-32. 
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Figure 10-32. Storage Area Holding Alternate Collating Sequence 
Instruction 


Consider the use of an altered sequence when determining 
which record to select for processing in a multifile program. 
The collating sequence.has been changed so that 2 comes 
nefore 7. . 


Fl and 1 —————> F1 and 2. 
F2 and 2 ——______> F2and1 


F3and3 —————» F3and3. 


Figure 10-33 illustrates how the program uses the alternate 
sequence. Two cards are read into the read area. Just be- 
fore the compare operation which is done to determine 
which match field has a lower value, the program checks to 
see if the characters used in the compare are affected by the 
alternate collating sequence instructions. They are. The 
character 7 normally associated with the value F1 is replaced 
by the character 2; the character 2 normally associated with 
the value F2 is replaced by the character 7. 


When doing the compare, the program substitutes these - 
values. For the match field having the character 2, the. 
program uses the bit combination whose value is F1 instead 
of the bit combination for F2. Similarly for the match field 
containing a 7, the program uses the bit combination of 

F2 instead of the bit combination for F1. As a result of the 
compare, the primary card containing a 2 in the match field 
is chosen for processing. This card was chosen because F1 
(now associated with character 2) is lower in sequence than 
F2 (now associated with the character 7). 


After the compare, characters are again associated with 
values as assigned in the normal collating sequence. 
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Figure 10-33. Using Alternate Collating Sequence (0, 1, 2, 3, 4, 9) 
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Coding Characters to be Equal 


Entries can be made to allow two characters to occupy the 


same position in the collating sequence; that is, they are as- 


sociated with the same numeric value. When two characters 
occupy the same position in the sequence, the computer 
recognizes one character as being the same as the other. 


International Business Machines Corporation 


Figure 10-34 illustrates the specifications which allow a 
blank or zero to occupy the same position in an altered 
sequence (assume the field is alphameric). The hexadecimal — 
value associated with the character blank is replaced by the 


hexadecimal value (FO) which 


is already associated with the 


zero. Because the zero and blank are associated with the 
same numerical value, they are recognized as the same char- 
acter. Figure 10-35 shows why a field containing a blank 


is equal to a field containing a 
quence is used. 
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Figure 10-34. Specifying Blank Equal to Zero in New Collating Sequence 
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Compare Field A to Field B 


Field A = Blank | Field B=0 


Bit combinations | i . . fs a - 
in storage a uss 
: Compare Field A to Field B. 


pi gaedd [11119000 | 





For compare should Alternate 
Collating Sequence be used? 








TI 
© 


Associated Character 


Normal . Altered 
Coll. Seq. | . Coll. Seq. 










Numerical 
Value of 
Bit Combinations 








Substituted bitin! 
bit combinations Ree tas eves 
Use Alternate Sequence. 
for Compare by Using 


Values Associated with 
Characters as Specified 


ge ce Sn Se ec ea es ees ey ee 
i : 
i —_——o— oo eee oe oe 


1111898d Compare to 11119998 }<————_—__—_—_ 


nn 
o 
n 
oO 


Result: FO is the same as FO 
Fields are equal; Blank 
is the same as zero. 


Figure 10-35. Using Alternate Collating Sequence (Blank Equals Zero) 
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Example of the Coding of an Altered Sequence 


Figure 10-36 shows a part of the normal collating sequence, 
and one of several ways in which the sequence can be 
changed. Arrows depict changes required in the positions 
of characters to alter the sequence as shown at the right side 
of the figure. 


In like manner, arrows in Figure 10-37 show entries on the 
coding sheet which must be specified to alter the sequence. 
Note that letters B through / are to be repositioned to allow 
the at-symbol (@) to appear between letters A and B. Iden- 
tical results could be achieved by repositioning the value for 
the letter A to the line above, making it correspond to bit 
combination 1100000. 


To produce the sequence shown in Figure 10-36 and 10-37, 
the appropriate hexadecimal values must be specified in the 
Replaced By column beside each graphic involved in the 
change. Figure 10-38 shows the actual coding required to 
alter the sequence. 


Notice that each number which is to be collated before the | 


alphabetic character is assigned a hexadecimal value which 
has no graphic associated with it. These values have no as- 
sociated graphics that could have been assigned to the values 
previously associated with numbers. This is not necessary, 
however, because these values have no associated graphics. 
When two graphics are involved in the change, then both 
must be assigned different values except when they are to 
be considered equal. 
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Figure 10-36. Normal Sequence Versus Altered Sequence 
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Figure 10-37. Changes Necessary for Altered Sequence 
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Figure 10-38. Coding for Altered Sequence 
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Recording Specifications for the Altered Sequence Coding Sheet. The last two positions in a group are for the 
hexadecimal value taken from the Replaced By column of 







After you have coded all specifications for the alternate col- the coding sheet (Figure 10-39). = C 
lating sequence, you can record them so that they can be ~ 
used by the computer. Records describing the alternate se- More than one record may be used to specify changes in 
quence are to be formatted as follows: collating sequence. However, each additional record must 
be formatted in the same way as the first. 
Positions Entries : 
1-6 ALTSEO (This entry allows the com- The first blank appearing in positions 9-96 is recognized by 
puter to recognize that this record is the compiler as the end of the record. Consequently, blanks 
describing an alternate sequence.) must not appear between pairs of hexadecimal values. 
7-8 Blank A record containing ** (two asterisks and a blank) in posi- 
tions 1 through 3 must precede the sequence records. 
9-96 The hexadecimal values involved in 
changing the sequence. All records (except the RPG I! control card) used for alter- 
ing the collating sequence must follow RPG II specifications 
In positions 9-96, there are 22 groups of 4 positions. Each (or file translation specifications, when used) and must pre- 
- group (9-12, 13-16, etc.) must contain two hexadecimal cede any tables being entered. : 
values involved in changing the sequence. The first two 
positions of a group are for the hexadecimal value taken 
from the Entry column of the Alternate Collating Sequence 
Note: Printed in USA. 
Although a card is shown in this ; HEET 
figure, remember, alternate collating 
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Figure 10-39. Punching Alternate Collating Sequence Cards 
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ALTERING THE STRUCTURE OF CHARACTERS 


You learned in the discussion of character structure that 
each System/3 graphic is represented in the machine by a 
unique setting of eight bits; four zone bits and four digit 
bits. If any change is made to either the zone or digit bits, 
the entire character is changed. For example, if the A bit 
of the letter M is changed from on to off, the letter M/ be- 
comes the letter D (Figure 10-40). 


You can, of course, change a character before it is read into 
the computer by punching different zone punches on the 
card. But you can also change a character after it has been 
read. This is done by changing the zones of characters 
through the use of move zone operation codes. 


Why would you ever want to change the zone of a character 
after it has been read? One common reason for changing 
zones is to deliberately change the sign of a field from posi- 
tive to negative, or vice versa. 


This is necessary when a numeric field read in from a special 
file has its sign in the high-order (leftmost) position of the 
field. Numeric fields are required to have the sign in the 
low-order (rightmost) position of the field. Thus, a numeric 
input field having its sign in the high-order position must 
have its sign moved to the low-order position. The move 
zone operations allow you to do this. 


84218 42 1 
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Figure 10-40. Changing Zones Changes Characters 


How Move Zone Operations Work 


Move zone operations involve only the zone portion of char- 
acters. The computer does not actually move the zone of 
one character to the zone portion of another. Rather, it 
changes a character by making its zone identical to the zone 
of the character which you indicate should serve as the 
model. The character serving as a model is not changed by 
the operation. 


Thus, in order to use the move zone operations you must 
have: 


1. A character which needs to be changed. 


2; A character that has the zone you want the changed 
character to have. 


For example, if you want the low-order (rightmost) position 
of the field AMOUNT to be changed from a positive 5 to a 
negative 5 you must have a character to serve as a model 
whose zone portion is the same as the zone of a negative 
five. 


Coding a Move Zone Operation 


Figure 10-41 illustrates the way in which a move zone opera- 
tion is coded. The name of the field containing the character 
to be changed must be entered in the Result Field. Either a 
constant of the name of the field which contains the model 
character must be entered in Factor 2. The move zone opera- 
tion code is specified in the Operation columns (28-32). 

Any conditioning indicators you wish to use can be speci- 
fied, but resulting indicators cannot be used. 
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Figure 10-41. Coding for a Move Zone Instruction 


Working With Data Structure 10-39 


Differences in the Move Zone Operations 


There are four different move zone operation codes avail- 
able. Each code involves the zones of characters located in 
different positions; namely: 


1. High-order positions in both Factor 2 and the Result 
Field. 


2. High-order position in Factor 2 and low-order in the 
Result Field. 


3. Low-order positions in both Factor 2 and the Result 
Field. 
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Factor 1 Operation Factor 2 
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Figure 10-42. Move Zone Operations 
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4. Low-order position in Factor 2 and high-order in thé 
Result Field. 


Since only the zones.of high and low-order characters ina 
field or constant are involved in the move zone operations, 
only the high or low-order positions of a Held can be 
changed. 


Figure 10-42 illustrates the ways in which the four opera- 


tion codes affect the zone of a character in the Result Field. 
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‘Numer 1 Field (Result Field) 


Result Field 


Factor 1 Operation Factor 2 


Numer 2 Field (Result Field) 


Sle 


Set 


Move From High-Order Zone to High-Order Zone (MHHZO) 


This operation code moves the zone of the high-order (left- 
most) alphameric character in the constant or field entered 
in Factor 2 to the high-order alphameric character in the 
Result Field. 


Move From Low-Order Zone to High-Order Zone (MLHZO) 


This operation code moves the zone of the low-order (right- 
most) character in the field or constant entered in Factor 2 
to the high-order alphameric character in the Result Field. 
The Result Field must be alphameric; Factor 2 can be either 
numeric or alphameric. 


Move From High-Order Zone to Low-Order Zone (MHLZO) 


This operation code moves the zone of the high-order alpha- 
meric character in the constant or field entered in Factor 2 
to the low-order rightmost character in the Result Field. 
Because of its high-order zone, Factor 2 must be an alpha- 
meric field. The Result Field can be either alphameric or 
numeric. 


Move From Low-Order Zone to Low-Order Zone (VULLZO) 


This operation code moves the zone of the low-order charac- 
ter in the field or constant entered in Factor 2 field to the 
low-order character in the Result Field. Both Factor 2 and 
the Result Field can be either numeric or alphameric. 


Field Format and Move Zone Operations 


As you read the description of each move zone operation, 
you probably noticed that special attention was given to 
the types of fields which can be used with each operation. 
Keep in mind that you cannot move from or to the high- 
order positions of a numeric field because the computer 
does not use the high-order zone of fields defined as 
numeric. 


Page of GC21-7567-2 
issued 21 December 1979 
By TNL: GN21-5709 


Which of the following move zone operations can be done 
if the two fields involved have formats as given below? 


1. Alphameric to Alphameric: MHLZO 
2. Alphameric to Numeric: MHHZO 

3: Numeric to Alphameric: MLHZO 

4. Numeric to Alphameric: MHHZO 

5. Numeric to Numeric: MLHZO 

6. Numeric to Numeric: MLLZO 


Items 7, 3, and 6 can be done. items 2 4, and 5 cannot be 
done. {tem 2 suggests that the zone of the high-order posi- 
tion in the numeric field be changed. The computer does 
not use high-order zone of numeric fields. Item 4 suggests 
that the zone of the high-order character is to serve as a 
model. /t cannot because the computer does not work with 
the zones of high-order characters in a numeric field. Item 
5 cannot be done because again it involves high-order posi- 
tions of numeric fields. 


Example of a Move Zone Operation 


Now that you know how the various move zone operation 
codes work, let’s see how they can be used to change the 
sign of the field, VALUE, from the high-order to the low- 
order position. 


Naturally any field that has zones other than in the low- 
order position must be defined as alphameric if those zones 


are to be used by the computer. But if the field is to be in- 


volved in an arithmetic operation, it must be numeric. 


To allow for both possibilities, you could define the field 
twice; once as alphameric and once as numeric. (Two 
unique field names are needed.) Another possibility is to 
define the field once as alphameric and then change it into 
a numeric field by moving it into a numeric field. This is 
what is done in the example (Figure 10-43). 
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Before doing any arithmetic operation, you must get the 
sign in the low-order position of a numeric field. You may 
want to first determine what the sign is by means of a 
TESTZ operation. Remember that TESTZ turns on the 
minus indicator when it finds the characters —, } , orJ 
through A in the high-order position of the tested field. 
The specification in Figure 10-43, insert B, line 02, causes 
indicator 20 to turn on if the sign of the field is minus. If 
indicator 20 is on, the zone of VALUE, which is the minus 
sign to the computer, is moved to the low-order position of 
the AMOUNT field. If the field tested is plus, no zone is 
moved because a numeric field having no minus sign is auto- 
matically assumed to be positive. 


Notice that the MHLZO (Move High to Low Zone) opera- 
‘tion code was used to change the zone of the low-order 
position of the AMOUNT field by giving it the same zone 
as the high-order position of VALUE. 


Note: This example can also be accomplished without us- 
ing a TESTZ operation. First, move the zone of the high- 
order position of the field VALUE to the low-order posi- 
tion. This puts the sign in the low-order position. The 
alphameric VALUE field can then be moved to the numeric 
AMOUNT field and the arithmetic operation can be per- 
formed. 


Choosing the Model Character for Factor 2 


Before specifying a move zone operation, you must have a 
character designated in Factor 2 whose zone will give the 
desired zone in the Result Field. 


Usually you will use move zone operations to change the 
signs of fields. Using any numbers in Factor 2 will produce 
a positive character in the Result Field. Using any one of 
the character 
character. The - (minus, X’60’) character does not work 
to make a character negative using the move zone opera- 
tion. Remember that negative numbers are punched with 
a B punch (minus sign) over the number. The punch com- 
binations of negative numbers have the same numeric value 
in the computer as J-R. Thus, when you specify that the 
zone of a character should be made like the zone of J-R, 
you will get a minus character. See Character Structure 
for more information. 


Use Figure 10-28 as a guide for selecting the zone which 
will produce the desired change. 
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Figure 10-43. Using Move Zone Operations to Change the Sign of a Field 
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TRANSLATING CHARACTERS 


In the previous discussion, you learned that the program 
can alter the structure of characters by moving zones. But, 
through the file translation function of the RPG II language, 
it can do even more. It can translate one character into an- 
other. 


The translating function is known as file translation because 
characters can be translated either when they are read in or 
before they are recorded in the output file. The program 
acts like an interpreter. Just as a human interpreter trans- 
lates languages (a word in German for a word in English), 
the computer translates characters by replacing’ one charac- 
ter with another. 


Need for File Translation 


Think of the use for file translation when translating codes. 
Codes are often used as a security measure to prevent access 
to classified information. Information is recorded on cards 
in coded form. In order to process the information, it must 
be decoded. A coded character must be replaced by the cor- 
responding decoded character. 


For example, a firm which keeps all information-classified 
uses the characters in the word FITZGERALD as a code 
for the numbers O through 9. F is the code for zero, / for 
one, etc. When recorded on a card, the number 1432 ap- 
pears as IGZT. If a field containing IGZT is read into the 
computer and used in arithmetic operations, results received 
are wrong. IGZT must first be decoded, or translated into 
1432. 


Specifying File Translation 


Specifications for file translation are identical to those used 
to alter the collating sequence. 


Forms Used for a File Translation 


Figure 10-44 shows the forms on which you must specify 
the way in which files are to be translated. One form con- 
sists of the RPG I! Control Card and File Description sheet; 
the other consists of the Translation Table and Alternate 
Collating Sequence Coding Sheet for listing the characters to 
be translated. Both forms are used in conjunction with the 
RPG If Input, Output, and Calculation sheets. 
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Only column 43 in the RPG 11 control card relates to the 
change in sequence. A letter F entered in column 43 noti- 


fies the computer that additional information furnished for c 


translating files. All other columns contain the information Ke 
that must normally be entered for a program. 


The Translation Table and Alternate Collating Sequence 
Coding Sheet lists 256 bit combinations along with their 
hexadecimal numerical values. You learned from discus- 
sions of character structure that the left-hand number in 
the hexadecimal value represents the numerical value of the 
character’s zone and the right-hand number represents the 
numerical value of the character’s digit: The 64 printable 
characters are listed beside the bit combination and hexa- 
decimal values with which they are associated. 


Coding the Translation 


Each character that will be affected during the translation 

of a specified file must be identified on the coding sheet. 

In the column entitled Replaced By, enter the hexadecimal 
value of the character which is to replace the character pres- 
ently associated with the bit combination shown. This 
means that the character associated with the value found in 
the Entry column will be translated into the character associ- 
ated with the value entered in the Rep/aced By column. 


Figure 10-45 illustrates the entry made on the coding sheet « 
to translate a character. If an input file is to be translated, 

this entry means that the letter F will be translated as the 
number O (FO is the hexadecimal value associated with 0). 
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Figure 10-45. Explanation of File Translation Coding Sheet C 
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If the output file is to be translated, this entry means that 
the number Q will be translated back into an F before being 


“written out. You can think of the character associated with 


the value in the Entry column as being the character read in 
or printed out. On the other hand, the character associated 
with the values in the Replaced By column is the character 
represented in the machine (Figure 10-46). 


Differences Between File Translation and Alternate 
Collating Sequence 


Because of the similarity of entries used in coding an alter- 
nate collating sequence and a file translation, these functions 
may seem identical. They are not, however. The difference 
occurs in the way the program works with the characters in- 
volved, 


When alternate collating sequence is used, the characters 
are altered only temporarily for sequencing operations. 
The original bit combination of the character, obtained 
from the punch combination for that character, is not 
changed. Temporary substitution of another bit combina- 
tion is done instead. 


For file translation, bit combinations are actually changed. 
As a result, one character is changed (translated) into an- 
other. This translation occurs before your program instruc- 
tions are executed. 


What Files Should Be Translated? 


Any input files which contain information recorded in 
coded form should be translated if correct results are to be 
obtained. All characters which you specify to be translated 
are translated whenever they are encountered. This means 
if you specify an F to be translated to 0, all F’s read in will 
be translated. When there are several other fields on the 
cards in addition to the one containing coded information, 
remember all characters specified to be translated are trans- 
lated regardless of fields. 


When printing or punching information out, you may or 
may not find it necessary to specify file translation for the 
output files. If you have translated (decoded) your input 
file, you should translate information back into coded form 
before it is written or punched out. If all F’s are translated 
as O's when read in, then all O’s should be translated to F’s 
before they are put out. Keep in mind that only characters 
which you specify are involved in the retranslation. 
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If you: ‘do not specify file translation for output files, in- 
formation i is put out exactly as it is in the machine. If you 
‘do not intend to translate card or printer output files, be 

_/ certain that all characters from the input file are translated 
into a value associated with a printable graphic. Any hexa- 
decimal value which does not have an associated graphic 
cannot be written or punched out (Figure 10-47). If an un- 
printable graphic is specified to be put out, a blank appears 
in its place. 
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Recording Specifications for the Translation Table 


After you have written all specifications for file translation, 
you can record them so that they can be entered into the 
system. Records containing these specifications must be 
formatted as follows: . 


Positions Entry 

1-6 *FILES 

or 

1-8 A filename 

7-8 Blank if not required 

9-96 Numerical values involved in translating 
characters 


If all files (both input and output) are to be translated, use 
the entry “FILES in positions 1 through 6. If only one file 


is translated, use that filename in positions 1 through 8. If - 


several, but not all files, are to be translated, you must for- 
mat separate records for each file. 


‘In positions 9 through 96, there are 22 groups of four posi- 
tions. Each group (9-12, 13-16, etc.) must contain two 
hexadecimal values involved in the translating of one char- | 
acter. The first two positions of the group are for the hexa- 
decimal value taken from the Entry column of the Transla- 
tion Table and Alternate Collating Sequence Coding Sheet. 
The last two positions are for the hexadecimal value taken 
from the Replaced By column of the coding sheet. 
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More than one record can be used to specify the characters 
which must be translated. However, each additional record 
must be formatted in the same way as the first. All records 
for one file must be grouped together. An error will occur 
if four records are entered in the following order: 


1.  FILEA 


2. FILEA 
3. FILEB 
4. FILEA 


Also, the first blank appearing in positions 9 through 96 is 
recognized by the computer as the end of the translation 
specifications. Consequently blanks should not appear be- 
tween pairs of hexadecimal values. 


A record containing **% (two asterisks and a blank) in posi- 
tions 1 through 3 must precede the file translation records. 


All records used for file translation except the RPG II con- 


trol card must follow RPG II input, calculation, and output 
specifications and must precede any tables or alternate col- 
lating sequence records used. -_ 


Review 10 


Character Structure 


1. Into what two portions may every column of a 96-column card and every byte in 
storage and on disk be divided? 


2. Do all characters that have an A zone punched in the zone portion of a 96-column 
card have the same zone representation in storage? Why or why not? 


3. ‘Calculate the numerical value of each of the following binary numbers as recorded in 
one byte of storage: 
a. 11000100. 
b. 11010101. 
c. 11101000. 
d. 11110011. . 


4. Express the numerical value of the bytes shown in Question 3 as a pair of numbers 
(hexadecimal value), rather than as a single value. 


Collating Sequence of Characters 
5, What does the computer use to determine the collating sequence of characters? 


6. Arrange the following characters in ascending collating sequence. Arrange the same 
characters in ascending collating sequence by zone and digit. 


Character Hexadecimal Numerical 
Value ‘Value 


C3 195 
61 97 
D7 
D1 


5C 


E3 


D9 


F4 


50 


FQ 


FO 
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Altering the Collating Sequence 
7. Fill in the Alternate Collating Sequence Coding Sheet to: : 
. Insert a U' between U and V (use the # sign to represent U). 


: Make a blank fall in the same sequence as zero. 


Show how this information would be recorded in an alternate collating sequence 
record. 


8. !n what RPG II operations is the alternate collating sequence used? . 


9. Where is the sign located in a numeric field? : 


Altering the Structure of Characters 


10. The TESTZ operation checks the zones of: 
a. any position in a field. 
b. only the low-order position in the field. 
c. only the high-order position in a field. 


11. A field may be alphameric for any move zone operations. Check those fields (Factor 
2, Result) which can be numeric for the following move zone operations: 


Operation 





12. Code the calculation specifications to make the contents of a Positive numeric 
AMTDUE field negative. 


Translating Characters 

13. What is the difference between the way the computer works with characters involved 
in an alternate collating sequence and the way it works with characters involved in 
file translation? 

14. Fill in the coding forms to translate A’s to 7’s and B’s to 3’s. Show how these speci- 


fications would be recorded in a translation table record when all files are to be 
translated. 
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ay 


Answers To Review 10 


Zone and digit. 


All characters which have the same zone punch in a 96-column card do not neces- 
sarily have the same zone representation in storage. There are four zone bits for 

each character in storage and only two zone positions in a 96-column card column. 
Therefore a translation must take place when the character is read. The computer 
checks the entire punch combination (both zone and digit) of a character to determine 
which bits are turned on or off in order to represent the character in storage. 


a. 196 
1 100 0100 
128+64+0+0 + 0+4+0+0= 196 
b. 213 oe 
c. 232 
d. 243 
a. C4 
1100 0100 
C= 8+4+0+0 + 0+4+0+0=4 
b. D5 - 
c. E8 
d. F3 


The computer uses the numerical values associated with characters to determine the 
collating sequence of characters. 
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6. When characters are collated by zone and digit, they are collated in this order: 


Character Numerical 
Value 





When characters are collated by zone the left half of the hexadecimal value is used to 

detérmine the order; when collating by digit the right half of the hexadecimal value is 

used. When characters are collated by zone or digit, several may hold the same posi- 

tion in the sequence and thus belong in the same group. Within that group they may 
_ hold any position. 


Characters collated by zone are in this order: Characters collated by digit are in this order: 


Hexadecimal 
Character Value Used 


Character — Hexadecimal 
Value Used 





* Characters within brackets * Characters within brackets 
may be in any order since may be in any order since 
10-52 _ they are in the same group. they are in the same group. 


International Business Machines Corporation 


TRANSLATION TABLE AND ALTERNATE COLLATING SEQUENCE CODING SHEET 














Form X21-9096 
Printed in U.S.A. 








Replaced Replaced Replaced Replaced 
System/3 By/Takes System/3 By/Takes System/3 By/Takes ome (sen By/Takes 
Code Graphic Entry Place Of Code Graphic Entry Place Of Code Graphic Entry Place Of Graphic Entry Place Of 
oorsoorn {| | | otsoorsro [Tos ST |S [toot | to TC a 
oo1ro100 [| [Ss SC _ottoorss | Ts? CT woolioio [| | OATS ttoonror 
| oooiot | | 35 +=+| 4} f omomo f o{[ 68 ff | | 10011011 | | 9B | 4 11001110 | 4 
y oonono [| isd] 36 CT orioioor | Cf oo CCCs 00100 J CT cc 14001111 
P oouoin | | oz SC] ooo [| GAT SCC™C~C~“‘(RS «CC tootstzo05, | CT CTs ttoto000:~* Ff CTC 
F ooo [CT eS] —=C‘ECSC;#CN «TT CC“‘“RS SCT noortsn0.« (COT ECT [_ttotooons ts TS 
sore -+}——}- 3 +] Haniotiar ee 00000 a riaoioare | 03 | 
00111010 3A }1oieeee9 {| AO — 
F 00111011, | PY Cfottortio | > ET ee M [ ow fC 
00111100 —— j01101111 |? | 6F {|  ~*i| {1010010 | = =~—Shr]| a2. S| —t—“*;é‘;é*rTSC*désCnt pong) ) STN CCU Og CTC 
Pootisor | Ss] 30S] SC SC*dCésT«cnttt000 «(| CT CdE:CsCs@{_ t0t001 «(| | CT CtC“‘(RS @ Cstonotsz09, [Oo =] oe =| Cs 
Yoouiio | | 3 | | {| ooo; [| =f 77 f+} {f 1010010 {[  —[ Aa [| gilts) ff} Bh} —____ 
ao i fh Lg | omiooie { | 72 | —} { sorooror |  [ ad [ |} J[ 41011000 | [D8 pe | 
| 01000000 | Blank [40 | F@ | fj ooo ff 7 ff toronto FT STS ttottoon RT oT 
T0000 7 PN ae oiTTOTOr ee eo 10101 ae PT BT 
| o1tio1ot | 75 |11011011_| 
ooooott [ON [as Contos, [Oe Tf tororoon sf SCL ttortio0. =O oc 
oroooioo | NNT ae fotttorsa Pf totototo A ee 
| oroooion | NY ts Tf orttto00 ff tototon PB tt071110 | [| oF [| 
oiooo1TT Sa aa a ioIoTiOT SS ao Se 
47 ] 01111010 ft: 7A | 10101103 | AD 
Potoorooo fT BSC cottttonn Feet 7a totorsto. eC tttooo0 Te 
 o1ooioon fof 0999100 ee re toro A viioooio [sf 2) OT 
| oroovoio ff ¢ CUT AN TT {_conaatton Pp | Ejottoo00 Bo ttoo0r SE 
yorooi011 fs faa VT cama he pe OOO f———— st | dys, | e¢ | | 
| oioonoo P< Of ac Notte Te | tottonno | 82 SEV SS ps | 7A | 
Poirier [¢ | j1oenn00 |__|. 8. fs fF ioisoom [Ts ee -e 
P oioiio f+ =| ae NN} 0000001 | st fz EE —— [67 | EQ | 
prs LL fa | yoooooio | | 2 SC*d:CSs |_ 20110107 pes TT | és [| £7 | 
{ororo001 | Tt SCOT Ss t0000100 ice Stott | | 67 | Pea | EG | 
| owroo10 | | s2CT Ss t0000107 | | 85 a] Ctortt000 | a 
a ———— 10000110 a I a KL a 
yoioicioo [Ta 10000111 at CL oto pa | EO | 
| ooioion | = dt cc CUT CC }S{_ 10001000 | sCsdT:S 88 Se | jot tont | ____F Bat ——] Pee 
| owiono | S| 56 CT CSCC toot001 «| CT tS Cds 0131100 | i eet so 
fovoro { | ss CT C*T:Csf_«t000 | | BO ee Speeees PERT 
|oiiio01 | ssf ofp S| CS ———————a | 10317411 | | BF | so Ee 
Torors010 [+ | sa || | 10001101 [+ | esto ee so re | 
Toronon |$ | se |. ae a S|, jinn eee <a 
gio |* {| sc ff se tnooooro. [BT ca 11110101 — FS 
Poronsmor fy) df sD TY a Samat eee aon Fe. 
Towutio |; | se {| | ie he 11110111 F7 Po 
010411 [| Ce COTCSd a 11000101 C5 | imino [a df Fe TC 
oiooo00 [- | eo CT Cd yooroorn | CE 11000110 C6 Puiniioor [a | ro 
f_orioo00n | | gt SCT | tootpt0 “TOC | c7 | | CO ttttoto ra 
Poroooro | Cf 2ST ST toronto [Ts CECT: 0000: fH —C‘<aE:C CST: SSC*dE:Céiéd;Cntntnn‘g’. S| | CTY 
foirooors | Tos Tf toot | | toro ft co atts TO re CT 
Potiooion | | af toot TC CT 11001010 CA pation | St Fo CUT 
01100101 10011000 11001071 cB puiiwio [ht re CT 
pv fe 


ALTSEQ 4@F9E57BE6E5E7E6E8E7E9E8 


123-4 5 6 7 8 9 WH 12 13 4 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 3t 32 


33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 $3 54 5S 56 57 S58 59 60 6) 62 63 64 


65 66 67 68 69 70 71 72 73 74 7S 76 77 78 79 6O 61 62 83 64 85 86 87 BB 89 90 91 92 93 94 95 96 


97 98 99 100 101 102 103 104 105 106 107 108 109 NO IM Nz NF M4 NS 16 117 NB NY 120 121 @2 123 124 125 126 127 128 


12 3 6 5 6 7 8 9 WH HN 12 13 14 1S 6 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 


33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 SO 5S! 5$2 53 S4 55 56 57 SO 59 60 Et 62 63 64 


B 
A 
8 
4 
2 
1 

B 
A 
8 
4 
2 
1 

B 
A 
8 
4 
2 
1 


“NAOMOPO-NAOPO-NHNSOYPTD 


65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 BO Bi 82 83 84 BS BE 67 BB 89 90 91 92 93 94 95 96 





IBM 3700 


Answers To Review 10 10-53 


8. An alternate collating sequence is used only for alphameric compare operations and 
matching or sequence checking operations done on match fields. — ; 


9. The sign of a numeric field must be in the low-order (rightmost) position of the low- 


order byte. 
10. C 
11. Factor 2 Result Field 
a. X 
b. X 
c. X XxX 
d. 





RPG CALCULATION SPECIFICATIONS 
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Form GX21-9093 
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Operation Factor 2 5 Comments 





13. In file translation a character is actually translated into another character because the 
computer changes bit combinations. All affected characters are changed for the entire 
program. The bit combinations for characters involved in an alternate collating 
sequence are not changed. Bit combinations are substituted for others during se- 
quencing operations only. 
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Chapter 11. DEBUG 


__ CHAPTER 11 DESCRIBES: 
How to use the DEBUG operation. 


| Format of records created by DEBUG. 


BEFORE READING THIS CHAPTER YOU SHOULD BE ABLE TO DESCRIBE: 


RPG II logic for indicators (see Chapter 1, RPG I! Logic). 


AFTER READING THIS CHAPTER YOU SHOULD BE ABLE TO: 


Code the Control Card and Calculation specifications necessary to employ the 
DEBUG operation. 


Place the DEBUG operation within your program so that it will provide meaningful 
data. 


Note: You can use the review questions at the end of this chapter to test your com- 
_ prehension of this topic. Answers follow the review questions. 


DEBUG . .11-1 


INTRODUCTION © 


A program that you write may not always work perfectly 
the first time or even the first few times it is run. The 
reason for this is that the program contains errors — errors 
that you were not aware you were making when you wrote 
the program. Some of the errors you can make are easy to 
find; others may be very difficult to find. Nevertheless, 
they all have to be corrected. But how do you do this? 
Where do you start? 


Just knowing the types of errors which are commonly made 


can give you a hint as to what you should check, _Most of / 


the errors made fall into one of the following categories: 


@ Incorrect use of RPG I! entries on the specifications - 
sheets. 


@ Errors in describing input data or the format of output | 


data. 


@ Errors in specifying the calculation operations. 


® Specifying calculation operations in the wrong sequence. | 


The RPG !! Compiler, when compiling your program, will 
diagnose the specifications to see if they contain errors. if 
they do, the compiler will print messages telling you the ' 
errors made. In this way, you can find errors made in the 
specifications. 


USING THE DEBUG FUNCTION 


You may, however, have made all correct entries on the 
sheets and still get the wrong results. What can you do 
then? You can, of course, check through your work. But 
this does not always show you where the error(s) lies. 


Sometimes, the specifications you write will not cause the 
computer to do what you think they will. It is often pos- 
sible to miss an error because you assume that a statement 
or group of statements needed to perform a certain task 
work correctly, when, in fact, they do not. For example, 
you may pass statement 06 believing it is correct when it is 
not and spend hours looking for errors in the rest of the 
statements which are really correct. 


It would certainly be helpful to you to find out just how | 
far along in your program everything is working correctly. 
But how can you find out information your program is 
working with at various points in your program? 


The RPG WJ language has a special Operation code which 
shows you some ‘of the information ‘the: computer is work- 
ing with. This code is known as the DEBUG code. The 
code received its name from the slang term “bugs” which 


_is used to mean errors ina program, To debug a program, 


therefore, means ‘to get all the errors out of it. This is what 
the DEBUG code helps you do. 


“” The DEBUG code will cause’a maximum of two different 
___ types of records to be printed or punched out showing 
7 you: * Balan hh he oe ieee Sead 


@ What data is contained in a specified field. 


gO Neko : 
es Mee ae 8 


@ What indicators are on. 


One of the most common errors found in a program is the 
incorrect use of indicators. If the programmer fails to 


‘. thoroughly understand RPG II logic, he may condition an 


operation using an indicator which he thinks is on when it . 


is Stcally not. Us ie piegiam does not work properly. 


hee 


le atany ee your calculations, you want to check to 


see if you are using indicators properly you can specify 
DEBUG. This code will cause a record to be put out show- 
ing what indicators are on at the point DEBUG is specified. 
If you wish to know the contents of a field in addition to 
knowing what indicators are on, you can also specify so in 
the DEBUG statement. A second record type will then be 
put out showing the contents of the field. 


Specifications for DEBUG 


When using DEBUG, the first specification which you must 
make is on the control card. A 7 in column 15 indicates 
that DEBUG is going to be used (see Figure 11-1). If this 
column is left blank, all DEBUG statements wil! be treated 
as comments. 


Then in columns 28-32 (Operation) on the Calcultion 
sheet, specify the code DEBUG. You may specify it at any 
point in the calculations and as many times as you want. 


For each DEBUG statement, enter in columns 33-42 (Factor 
2) the name of the file on which DEBUG records will be 
written or punched (see Figure 11-1). Use the file name 
previously assigned on the File Description sheet. The same 


output file must be used for all DEBUG operations ina Bigs 
gram. 


\ 
~ 
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RPG CONTROL CARD AND FILE DESCRIPTION SPECIFICATIONS 
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Figure 11-1. Specifications for DEBUG 
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Control Card Specifications 


a 

5 20 8 

g 2 alz E 3 

2 . as 3 512 els g z = 3 

= slSls| |= Sle] slelS[a/s! |= Slo 

S #lslc|s Siac} 8] sislalz 9 

8] Adcress | HISIE(SIEIEI lElelel el clelsiel |SISLETEIE 
The entry 1 in this column indicates that all DEBUG 
specifications should be performed; a blank indicates that 


all DEBUG specifications will be treated.as comments. 





RPG CALCULATION SPECIFICATIONS 


ji: Electro Number 
recone Pomme | TL] yy ene 
mewn Tree TTT ETT 
. Result Field 


Operation Factor 2 
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Refer to the specific System Reference Library manual for actual entries. 
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The entries just described will give you a record showing 
what indicators are on. If you also want to know the con- 
tents of a field, you must make another entry: The name 

-of the field whose value you wish to know must be entered 
as the Result Field in Columns 43-48 (see Figure 11-2, in- 
sert A). | 


Columns 18-27 (Factor 1) are optional. If you have several 
DEBUG statements, you may wish to know which records 
were caused by a particular DEBUG statement. You can 
name the DEBUG statement by entering a literal in columns 
18-27. This name will then be included in the records which 
the statement causes to be put out (see Figure 11-2, insert ~ 
B). 


Columns 7-17 may contain any valid conditioning indicator. 
The external indicators U1-U8 are most often used here. 
They make the DEBUG statement optional. Through their 
use you can establish, prior to a run, whether or not you 
wish to use DEBUG (see Chapter 5, Controlling Operations 
in an RPG II Program for uses of U1 to U8). Columns 
53-59 cannot be used for the DEBUG statement. © 


RPG CALCULATION SPECIFICATIONS 
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Format of Records Created by DEBUG 


Two records may be created by the DEBUG operation. 
Record 1 is required; Record 2 is optional. Record 1 (Fig- 
ure 11-3) will look like this: 


Positions 
1-8 


9-16 


17:18 
19-33 
34 
35-37, 


38-40, 
etc. 


Punching 
eee ome Pee 
Resulting 


Factor 1 Operation Factor 2 


cee 22.23 24 25 


eo 
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Figure 11-2, Additional Entries Which Can Be Made for DEBUG 
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Entry - 

DEBUG = 

The name entered in Factor 1 of the de- 
bug statement. These columns will be 
blank if no entry is found in Factor 1. 
Blank 

INDICATORS ON = 


Blank 


Name of the indicators which are on. 


Each indicator is followed by a blank. . 
If a large number of indicators are on, 
more than one record may be required 
to show all indicators. . 


Form GX21-9093 
Printed in U.S.A. 
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ee es 
Identification 


Comments 
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Record 2 (Figure 11-3) will look like this: 


Positions Entry 
1-14 FIELD VALUE = 
15 — The contents of the field named as the 


result field in the debug statement. If 
the field is rather large, only 80 of the 
rightmost characters are displayed. 


; 


Getting Results from DEBUG 


DEBUG will not automatically provide you with the specific 
reason your program is in error. But by showing the indica- 
tor setting and contents of fields at various points, it can 
give you a clue as to where the error lies. From there, you 
will have to work through the logic of sections in your pro- 
gram to find specific bugs. 


Placement of DEBUG 


' DEBUG statements can be placed anywhere in the calcula- 


tions. However much thought should be given to their posi- 
tion, If they are not placed in proper positions, they may 
give misleading information and be of no help at all. For 


Record 1 


example, if you are concerned about the status of an indica- 
tor at a certain point in your program, be sure to position 
DEBUG so that the indicator has no chance to change be- 
fore it is displayed. 


_ If you want to find out if a statement or group of state- 


ments is working correctly you must know what is in the 
field involved immediately before and after the statement(s). 
This means placing DEBUG before and after the state- 
ment(s) you are checking. In order to determine if the re- 
sults obtained from these statements are correct, you will 
have to manually make the same calculations and compare 
the two results. In this case, however, you must make cer- 
tain your own calculations are correct. Much time can be 
wasted trying to make the computer arrive at the same 
wrong answer you have calculated. 


Making Your Program Work for All Cases 


Be certain that you test your program to see that it will 
handle correctly all possible situations which might arise. 
If you test for only one or two situations, you can be sure 
your program works only for those situations. This means 
that the data you use to test your program be complete 
and valid so that it tests all possible situations. In this way, 
you can be sure your program can handle all situations 
without encountering hidden ‘bugs’. 


DEBUG = DEBUG 1 INDICATORS ON = 20 42 02 11 MR 


Record 2 


FIELD VALUE = 005648219R 


Figure 11-3. Format of DEBUG Records 
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Review 11 


What does DEBUG do in an RPG II program? 
Write a DEBUG statement to display on the file called OUTFILE a field called 


ANSWER and the indicators that are on at this point. Identify the DEBUG records 
with the constant - TEST1. What entries in other specification sheets must be made? 


Review 11 11-7 


Answers To Review 11 


1. DEBUG allows you to display the contents of a data field in your program and to list the 
indicators that are on. 


2. A 1 must be entered in column 15 of the RPG II control card. 


RPG CALCULATION SPECIFICATIONS fom ox 
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*(asterisk; star), printing on cards 4-3 
**(look ahead fields) 5-21 
*PLACE 3-19 
conditioning by indicators 3-22 
used with EXCPT 7-26 
*PRINT (unformatted printing on cards) 4-6 


accumulating totals 5-59 
advancing printer forms 3-6 
aligning printer forms 3-12 
altering character structure 10-38 
altering the order of file processing 7-2 
alternate collating sequence 10-27 
alternating format : 
arrays 93 
tables 812 
alternating processing of files 7-4 
ALTSEQ card 10-38 
arithmetic operations 
using i*.2 results 5-13 
arrays 
accumulating groups of totals 9-14 
adding elements (XFOOT) 98 
array to array calculations 9-4 
calculations with single fields or constants 9-7 
compile time arrays 9-35 
defining 9-2 
of different lengths 9-7 
editing 9-11 
execution time 9-38 
indexing 9-20 
toading 
compile time 9-36 — 
execution time 9-38 
pre-execution time 9-36 
LOKUP 9-27 
MOVEA operation 9-44 
operation codes, restrictions 9-7 
output 
duringa search 9-34 
of anentire. array 9-9, 
of individual elements 9-22 | 
pre-execution time 9-36 
referencing all elements 9-4 
referencing individual elements 9-19 
referencing part of anelement 9-23 
- storing data into (see loading) 
when to use array instead of table 9-2 
XFOOT 9-8 
artificial contro! break (LO) 5-56 
asterisks, punctuating with 3-16 
automatic overflow (page formatting) 3-2 


Index 


balances (see editing) 
BEGSR (begin subroutine) operation code 5-48 
binary field operations 5-67 | 
BITOF operation code 5-67 
BITON operation code 5-67 
TESTB operation code 5-68 
binary format 10-19 . 
BITOF (set bits off) operation code 5-67 
BITON (set bits on) operation code 5-67 
bits (numerical value of) 10-13 
blank after function (with resulting indicators) 1-31 
branching in calculations 
backwards 5-42 
bypassing calculations 5-36 
for anerror condition 5-41 
GOTO operation code 5-36 
ina matching records job 5-41 
repeating calculations 5-42 
TAG 5-36 
when different record types require e different operates 5-41 
bypassing calculations 5-36 
bytes, definition 10-4 ; = a 


calculation specifications 
using results of arithmetic operations 5-13 
for arrays 
accumulating groups of totals . 9-14: 
adding all fields (XFOOT) 9-8 
array toarray. 9-4. 
using single fields or constants . 9-7 
binary field operations 5-67 
branching 5-36 
conditioning 5-7, 5-12, 5-59 
subroutines 5-44 
used to control input and output 7-1 
using table data 8-14 
(see also individual operation codes) 
card column structure 10-2 
card path, MFCU (diagram) 5-17 
card type, stacker selection basedon 4-15 
cards, printingon 4-2 ay 
cards, stacker selection of 4-14 
carriage tractors (see dual feed carriage) 
catch-all record identifying indicator 2-15 : 
CHAIN operation code (see /BM System/3 RPG II Disk File 
Processing Programmer’s Guide, GC21-7566) 
changing field type 5-34 
changing array data 
compile time 9-36 
execution time 9-38 
pre-execution time 9-36 
changing table data 
compile time 8-22 
pre-execution time 8-26 


Index X-1 


—_— 


character set 10-2 
character groups with zones that test equal 10-9 
character structure 
altering 10-39 
oncards 10-6 
negative number 10-3 . 
in storage (core or disk) - 10-4 ..- 
characters, translating. . 10-44 
checking for duplicate records” 
using look ahead 5-20 
using move operations 5-31 - 
checking sequence of records 
using match fields 6-2 
using move operations 5-31 . 
checking sequence of record types * 2-6 
codes, use in file translation 10-44 
collating sequence BS 
altering of 10-30 
ALTSEQ card 10-38 
specifications 10-38 
by zone or digit 10-25 
combined file 
definition 48 
used with look ahead 5-28 ~ 
used to read and punch the same card 4-8- 
used with stacker selection 4-14, 4-17 
compare operations 
using the results 5-14 
compile time arrays 935 
compile time tables 8-25 
conditioning calculations 
based on information in next card 5-17 
based on LOKUP operation 8-14, 9-27 
based on results of other calculations © 5-12 
using external indicators 5-7 : 
using halt indicators 5-2 
using overflow indicators 5-11 
conditioning use of input files 2-19, 2-22 . 
conditioning operations when storing array data 9-49 
conditioning output operations 5-2 
conditioning subroutine statements 5-54 
consecutive file (see /BM System/3 RPG II Disk File Precening 
Programmer’s Guide, GC21-7566) 
in calculations with arrays 9-7 
use inediting 3-18 
control break 2-2 
artificial (LO) 5-56 
control card a 
alternate collating sequence 10-38 
file translation 10-48 _ 
setting external indicators (Model 10 Card d System 2-21 
control fields 
definition 1-5 
logic for initial program cycles” 1-7 
with field record relation ‘2-18 - 
with match fields 634 © 9° ee 
split control fields 2-5 oe * ¥ 
control! group 
determining first only record in 5-26 
determining last record in 5-28 , 
incorrect records in 2-11 
number of each record type in 2-11 


Index X-2 


optional record types in 2-11 
order of recordtypesin 2-6 
sequenced and unsequenced record types 2-14 
unexpected or unused record types in 2-14 
control level indicators 
artificial control break (LO) 5-56 
to condition calculations 5-59 
to condition subroutines 5-54 
first cycle difference 1-7 
general use 1-5 
group printing 5-59 
special use 5-55 
controlling printer output . 3-1 
cycle, Ru Il logic 1-1 
first cycle 1-7 
last cycle 1-16 


dashes, punctuating with 3-16 
data structure 10-1 
binary format 10-20 
negative numbers 10-3 . 
packed decimal format 10-19 
unpacked decimal format 10-19 
DEBUG function 11-1 
format of debug records 11-4 
decimal positions in table entries 8-7 
demand files (READ operation) 7-24 
end-of-file indicator 7-24 
coding rules and considerations 7-26 
designing table,input records 8-4 
detail time 
logic 1-6 
Operations 1-4 
device name, dual carriage printers 
PRINTER; PRINTR2 3-28 
TRACTR1; TRACTR2 3-29 
digit, collating by 10-25 
digit portion of character 
card 10-2 
disk 10-4 . 
direct files (see /BM System/3 RPG II Disk File Processing : 
Programmer’s Guide, GC21-7566) 
dollar sign, punctuating with 3-14. 
fixed 3-14 
floating 3-14 
dual feed carriage printer 3-27. . 
dual input/output areas 5-69 


dummy match field 6-10 


duplicate information, printing (*PLACE) - 3-19 
duplicating constants 3-24 ne 
duplicate records, checking for 5-20 


edit codes 3-12 ya 
chart 3-13 is 
edit words 3-12, 3-16 
editing 
definition 3-12 
arrays 9-11 


D 


with asterisks 3-16 
with blanks 3-18 
oncards 4-8 
with constants 3-18 
with dashes 3-16 
end position 3-19 
fixed dollar sign 3-14 
floating dollar sign 3-14 
zero balances 3-13 | 
zero suppression 3-13 
element 
array 92 
table 82 
end-of-file 
input file 2-23 
FORCE operation 7-11 


multi-file processing 6-30 
READ operation (demand files) 7-24 
end of job (see end-of-file external indicator; halt indicator; 
last record indicator) 
end position 
when editing 3-19 
when using *PLACE 3-22 


ENDSR operation code 5-48 
entries (see table entries) 
equal search condition 98-19 


error conditions 5-41 
(see also halt indicators, H1-H9) 
errors in program, finding 11-1 
EXCPT operation code 7-26 
conditioning EXCPT 7-29 
used inaloop 5-42 
with *PLACE 7-26 
execution time arrays 9-38 
EXSR operation code 5-48 
extension specifications 


for arrays 9-2 
for one table 8-5 
for two tables 8-13 


external indicators (U1-U8) 


conditioning input files and calculation operations 5-7 
conditioning input files 2-19, 2-22 
conditioning input files and output operations 5-8 
conditioning output file and output operations 5-9 


conditioning output operations only 5-11 

setting on Model 10 Card System (indicator contro! card) 2-21 

setting on Model 10 Disk System and Model 15 (SWITCH OCL 
statement) 2-21 


setting on Model 6 (SWITCH keyword) 2-22 


fetch overflow 3-8 


field indicators, logic 1-25 
field record relation 
with control fields 2-18 
with match fields 6-8 


OR relationship with 2-16 
field scanning 9-23 
file designation 

determining whether file should be primary or secondary 6-38 
file translation 10-42 


| final totals, printing 5-59 


first page (1P) indicator, logic 1-13 

first program cycle 1-7 

fixed dollar sign 3-14 

floating dollar sign 3-14 

FORCE operation code 7-2 
altering the order of file processing 7-2 
alternating processing between two files 
controlling number of FORCE operations 
controlling processing at end-of-file 7-11 
effectonMR 7-22 : 
with look ahead 7-15 a Bs 
performing matching records without match fields 7-15 
use of trailer card 7-12 

format of data (see data structure) 

format of DEBUG records 11-4 

formatted printing on cards 4-2 

formatting reports 3-2 

forms advance (fetch overflow) 

forms alignment 3-12 

formslength 3-4 


7-4 
7-9 


3-12 


GOTO operation code 5-36 
group indication 2-2 


group printing 5-59 


halt indicators - 
conditioning operations 
logic cycle 1-35 
halting 
for record out of sequence inacontro|l group 2-10 — 
for record out of sequence inafile 6-5. 
forerrorsin data 5-2 be 
for incorrect record type in a control group 2-13 
hexadecimal values (chart) 10-18 . : 
high search condition 
arrays 9-31 
tables 8-19 


5-2 


increasing speed of input and output (dual! I/O area) 5-69 
indexing arrays 9-20 
indicators 
definition 1-2 
control level (L1-L9) 
function 1-5 
special uses 5-55 
to control calculations and output 5-2 
externa! (U1-U8) ae 
conditioning operations 
setting 2-21 


5-7 rhe 


field indicators, logic 1-25 5 
field record relation 2-16 
first page (1P), logic 1-13 


halt indicators (H1-H9) 
logic 1-35 


to prevent operations on anerror 5-2 


Index X-3 


last record (LR), logic 1-16 
LO 5-55 
matching records (MR), logic 1-42 
overflow (OA-0G, OV) 3-4 
record identifying, logic 1-19 — 
resulting 
logic 1-31 
use with arithmetic operations 5-13 
setting indicators (SETON, SETOF) 1-43 
indicator control card (Model 10 Card System) 2-21 
input areas, dual 5-69 
input data, storing in execution time arrays 9-38 
input files , 
conditioning use of 2-19 
merging input and output cards 4-27 
stacker selection 4-14 
input, programmed control of ‘7-1 
input records 
arrays 9-35 
tables 8-4 
interpreting punched data 4-2 


last record (LR) indicator, logic 1-16 
level indicators (see control level indicators) 
line counter specifications 3-4 
loading arrays 

compile time 9-36 

execution time 9-38 

pre-execution time 9-26 
loading tables 

compile time 8-25 

pre-execution time 8-26 
logic, basic data processing 1-2 
logic, RPG 11 (see RPG II jogic) 
LOKUP operation code 

arrays 9-27 

with one table 8-7 

with two tables 8-14 
look ahead feature 

checking for duplicates 5-20 

with combined or update files 5-28 

finding last record in group 5-28 

with FORCE 7-15 

logic cycle for 5-23 

with MFCU files 5-17 

records available 5-18 

to find single record groups 5-26 

specifications 5-20 
loop in calculations 5-42 
loop with EXCPT 5-42 
low search condition 

arrays 9-33 

‘tables 8-20 
LR (last record) indicator 1-16 
LO (internal control level indicator) 5-55 , 
L1-L9 indicators (see control level indicators) 


Index X-4 


match fields 
assigning, rules for 6-7 
with control fields 6-34 
definition 6-1 
dummy match field entry 6-10 
with field record relation 6-8 
rules 6-10 
in different locations ina file 6-26 
M1-M9 entries 6-2 
sequence checking with 
one record type infile 6-2 
more than one record type 6-6 
matching records 
definition 6-2 
with control fields 6-34 
end-of-file with 6-30 
first cycle 6-14 : 
performed using FORCE with look ahead 7-15 
logiccycle 6-14, 6-38 
more than one matching secondary 6-12 
more than one record type inafile 6-26 
one record type in each file 6-12 
processing records without match fields 6-29 
record identifying indicator with 6-14 
total operations with 6-14, 6-34 
matching records indicator (see MR) 
merging input and output file cards 4-24 
MFCM output operations 4-1 
printing oncards 4-2 
formatted 4-5 
unformatted (*PRINT) 4-6 
punched output 4-2 
combined files 4-8 
stacker selection 4-14 
MFCU files, look ahead with 5-17 
MFCU output operations 4-1 
printing oncards 4-2 
formatted 4-3 
unformatted (*PRINT) 4-6 
punched output 4-2 
combined files 4-8. 
interpreting punched data 4-2 
summary punching . 4-2 
stacker'selection 4-14 
MHHZO (move high order zone to high order zone) 
operation code 10-40 
MHLZO (move high order zone to low order zone) 
operation code 10-40 
MLHZO (move low order zone to high order zone) 
Operation code 10-40 
MLLZO (move low order zone to low order zone) 
operation code 10-40 
modifying table contents 8-22 
MOVEA operation code 9-44 
move zone operation codes 10-39 
example 10-41 
field format 10-41 
model character 10-42 
operation codes 10-41 
moving data 
to change the fieldtype 5-34 
MOVE operation code 5-29 
MOVEL operation code 5-29 


BX 





tosa_ information 5-31 
to separate fields into two parts 5-33 
inatableentry 8-22 
/ MR (matching records) indicator 
effect of FORCE on 7-22 
logic cycle 1-42 
used to condition subroutines 5-54 
whenon 6-17 
when turned on 6-14, 6-22 
multifile processing 
definition 6-2 
end-of-file specification 6-30 
general description of logic 1-42 
(see also match fields; matching records; MR indicator) 
M1-M9 (see match fields) 


negative numbers, structure of 10-3 
number of each record type in a control group 2-11 
numerical values : 

of bit combinations 10-12 

of zone and digit portions 10-15 


object program cycle (see RPG 1! logic) 
operation codes 


BEGSR 548 
BITOF 5-67 
: BITON 5-67 
) DEBUG 11-1 
ENDSR_ 5-48 
EXCPT 7-26 
used in loop 5-42 
EXSR_ 5-49 
FORCE 7-2 
GOTO 5-36 


LOKUP 8-14, 9-27 
MHHZO 10-40 
MHLZO- 10-40 
“MLHZO~ 10-40 
MLL2O- 10-40 


MOVE 5-29 

| MOVEA 9-44 
MOVEL 5-29 
READ 7-22 
TAG 5-36 
TESTB 5-68 
TESTZ 5-14 
XFOOT 9-8 

operations 


arithmetic, using results of 5-13 
binary field 5-59 
compare, using results of 5-14 
controlling with look ahead 5-17 
detail 1-4 
total 1-4 
optional record types ina control group 2-11 
OR relationship 2-15 
with field record relation 2-16 
a with stacker selection 4-15 


| 
a 


output-format specifications 
arrays 
during an array search 9-34 
entire array 9-9 
individual fields 9-22 
dual feed carriage printer 3-27 
stacker selection using 4-15 
using table data 8-14 
Output areas, dual 5-69 
Output cards 
merging with input cards 4-19 
stacker selecting 4-17 
Output operations 
conditioned by external indicators 5-8 
MFCU 4-1 
output, printer 3-1 
Output, programmed control of 7-1 
Output, table 8-28 
overflow 
automatic 3-2 
fetch overflow 3-8 | 
calculations with 5-11 
indicators 1-41, 3-2 
line counter specifications 3-4 
logic 1-41 
overflow line, standard 3-2 


“overlay, controlling with subroutines 5-54 


packed decimal format 10-19 
*PLACE 
with constants 3-24 
different spacing 3-23 
with EXCPT 5-42 
formation of print lines 3-22 
with indicators 3-24 
specifications 3-22 
pre-execution time arrays 9-36 
pre-execution time tables 8-25 
preventing operations when an error occurs 5-2 
primary files, determining whether files should be primary or 
secondary 6-38 - 
primary tractor (dual printer files) 3-37 
PRINTER device name 3-28 
*PRINT 4-6 
Printer files, dual 3-27 
printer forms alignment . 3-12 
printer forms, designing 3-12 
printer output, controlling 3-1 
printing duplicate information 3-19 
printingoncards 42 
printing only final totals 5-59 
printing over the perforation 3-6 
PRINTER2 device name 3-28 
print-head (MFCM) 4-5 
processing order of files (see matching records; multifile processing) 
program cycle 1-2 
(see also RPG II logic) 
programmed control of input and output 7-1 


Index X-5 


program errors, finding (see DEBUG) 
punch combinations 10-2 
punched output (MFCU) 4-2 
summary punching 4-2 
punching into a blank card 4-11 
punching into the same card that is read 4-8 
punctuating a field (see editing) 


reading and punching the same card 4-8 
READ operation code 7-22 
record identification code 2-6 
record identifying indicators 
catch-all indicator 2-15 
in field record relation 2-15 
logic for 1-19 
with matching records 6-14 
in sequence checking record types 2-9 
recording specifications for an altered collating sequence 10-38 
records, designing table input 8-4, 8-11 
record types 
branching in calculations for different 5-41 
OR relationship of 2-15 
sequence checking of. 2-9 
reducing coding and storage requirements 
in calculations (subroutines) 5-44 
in describing similar or identical records (field record 
relation) 2-15 
when printing duplicate information 3-19 
when punching and printing cards 4-8 
reducing job time 
dual input/output areas 5-69 
referencing individual array elements 9-19 
related tables 8-13 
repeating calculations 
by branching 5-42 
using subroutines 5-45 
repeating the first print line 3-12 
repetitive output (EXCPT operation) 7-26 
resulting indicators 
with arithmetic operations 5-13 
logic for 1-31 
with LOKUP 8-7, 9-27 
with READ 7-22 
with TESTB 5-68 
rolling of totals (arrays) 9-14 
RPG 1! logic 
detail time 1-6 
fetch overflow 3-8 
first programcycles 1-7 
related to indicators 1-7 
field indicators 1-25 
first page (1P) indicator 1-13 
halt indicators (H1-H9) 1-35: 
last record indicator (LR) 1-16 
matching records indicator (MR) 1-42, 6-14 
overflow 1-41 
record identifying indicators 1-19 
resulting indicators 1-31 
setting indicators 1-43 
totaltime 1-6 


Index X-6 


saving disk storage space 
binary data format 10-20 
packed decimal format 10-19 
saving information by move operations 5-29 
scanning fields 9-23 
searching arrays 9-27 
determining search success 9-30 
fora particular element 9-27 
output during search 9-34 . 
starting the search at a particular element 9-28 
referencing the element found 9-31 
searching tables 8-2 
for high, low, or equal 8-19 
referencing the data found 8-16 
secondary file 
determining whether a file should be 6-38 
secondary tractor (dual carriage printer) 3-27 
selecting a stacker onthe MFCU 4-14 
separating a field into two parts 5-33 
sequence checking 
by calculation specifications 5-31 
of a file using match fields 6-2 
of record types in acontrol group 2-6 
sequential disk file (see /BM System/3 RPG I! Disk File Processing 
Programmer’s Guide, GC21-7566) 
setting external indicators 2-21, 2-22 
setting indicators (SETON, SETOF) 1-43 
SETOF operation code 1-43 
SETON operation code 1-43 
short tables 8-23 
skipping 3-29 
skipping calculations (branching) 5-36 
spacing 3-29 
split control fields 2-6 
with field record relation 2-18 
SR (subroutine) lines 5-48 
stacker selection 4-14 
at total time 4-17, 5-10 
of combined file cards 4-17 
of input cards 
based on calculations 4-15 
based on cardtype 4-15 
of output file cards 4-17 
of unmatched records 6-24 
standard forms length 3-2 
standard overflow line 3-2 
storing data into execution time arrays 9-38 
structure of characters (see character structure) 
subroutines 
calling 5-48 
conditioning 5-54 
fields available 5-49 
limitations 5-52 
overlays 5-52 
repeating calculations 5-45 
specifications 5-48 
valid operations in 5-52 - 
| subtotals (group printing) 5-59 


+ 


summarizing data (group printing) 5-59 
summary punching 4-2 
example 5-10 
suppressing leading zeros 3-13 
SWITCH keyword (Model 6) 2-22 
SWITCH OCL statement (Model 10 Disk System and! 
Model 15) 2-21 
switches 


binary field operations 5-67 


tables 8-1 
assigning table names 8-6 
binary table data 8-7 
compared to arrays 92 
compile time 8-25 
definition 8-2 
describing input records 8-5 
designing input records 
one table 8-4 
two tables 8-11 
entries with decimal positions 8-7 
length of entry 8-6 
loading 8-25 
modifying contents of 8-22 
moving data inanentry 8-22 
number of entries per input record 8-4, 8-6 
number of entries per table 8-6 
number of input records required 8-4 
output 38-28 
packed table data 8-7 
pre-execution time 8-25 
related 8-8 
searching 8-2, 8-14 
sequence 8-7 
short 8-23 
TAG operation code 5-36 
TESTB operation code 5-60 
testing the contents of afield 5-12 
TESTZ operation code 5-14 
character groups with zones that test equal (table) 
total operations 
logic 1-6, 6-38 
with matching records 
tractors (dual carriage printers) 


10-10 


6-14, 6-34 
3-27 


TRACTRI1 device name 3-29 
TRACTR2 device name 3-29 
trailer card 

use in force operation 7-12 


translating characters 
coding for 10-44 
forms used 10-44 


unexpected record types inagroup 2-14 
unformatted printing on cards (*PRINT) 4-4 
unmatched record 

stacker selection of 6-24 
unsequenced record types in acontrol group 2-14 


update files, look ahead with 5-28 
U1-U8 indicators 2-19 


XFOOT operation code 9-8 


zero balances 3-13 

zero, negative 10-3 

zero suppression 3-13 

zone portion of character 
collating by 10-25 
testing (TESTZ) 5-14 
zones that test equal (table) 

zone punches’ 10-2 


10-10 


0A-0G, OV indicators (see overflow indicators) 

01-99 indicators (see record identifying indicators; resulting 
indicators; field indicators) 

1P indicator logic for 1-13 

1403 Printer 3-2 

2222 Printer 3-27 

2560 MFCM 4-2 

5203 Printer 3-27 

5213 Printer 3-2 

5424 MFCU 4-2 
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